From: Mark Lorenzen <mark.lorenzen@ofir.dk>
Subject: Re: Combining entry_call, accept_statment and terminate_statment
Date: Tue, 30 Mar 2004 01:19:34 +0200
Date: 2004-03-30T01:19:34+02:00 [thread overview]
Message-ID: <m3vfkn6y2h.fsf@niflheim.malonet> (raw)
In-Reply-To: 106h7clrs4iio8c@corp.supernews.com
"Randy Brukardt" <randy@rrsoftware.com> writes:
[cut]
>
> But I'd say that you probably have a design problem if you have a task that
> is both calling and accepting at the same time. That's pretty weird (unless
> the accepts are purely for task control, as above). It's preferable that
> each task be either a server (accepting entries) or a client (calling
> entries), but not both. Analysis is complicated if you have both.
>
> Randy.
To me, this seems to be a severe design limitation. Isn't it normal to
have a task acting as a filter, i.e. reading data from a PO,
manipulating the data and the writing the manipulated data to a PO?
This could f.x. be a task implementing a (de)multiplexer.
- Mark Lorenzen
next prev parent reply other threads:[~2004-03-29 23:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-29 19:41 Combining entry_call, accept_statment and terminate_statment Lutz Donnerhacke
2004-03-29 22:04 ` Randy Brukardt
2004-03-29 23:19 ` Mark Lorenzen [this message]
2004-03-29 23:14 ` Robert I. Eachus
2004-03-30 7:26 ` Lutz Donnerhacke
2004-03-30 20:04 ` Randy Brukardt
2004-03-30 22:47 ` Lutz Donnerhacke
2004-03-31 9:03 ` Dmitry A. Kazakov
2004-03-31 9:14 ` Lutz Donnerhacke
2004-03-31 12:22 ` Dmitry A. Kazakov
2004-03-31 6:39 ` Jean-Pierre Rosen
2004-03-30 7:29 ` Lutz Donnerhacke
2004-03-30 8:11 ` tmoran
2004-03-30 11:45 ` Lutz Donnerhacke
2004-03-30 0:33 ` James Rogers
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox