[Stackless] Stackless based replacement

[Larry Dickson]

Hi Andrew,

We seem to have different ideas of what is simple. You propose exceptions,
waits, signals, barriers, re-initialization, and presumably global signal
values. This in my opinion is a whole Italian restaurant of spaghetti, and
it sounds intrinsically global, which is poison to maintainable
multiprocessing in my experience. Of course I could be wrong, having little
experience with your way of doing things, except for standard C/Linux
signals. (Have you ever tried setting anything up with occam manager and
workers?)

The beauty of toplevel (stackless in the generic sense) processes
communicating through channels is that they do not have to share resources
OR KNOWLEDGE with other black boxes of the same construction but totally
different function and/or history. This is what drivers try to be but never
succeed. A manager based on ALT (or stackless_receive_first) can manage
several of these black boxes - possibly of completely different types, like
ethernet and disk - and apply optimal strategies to the data flow without
digging deep into the driver code. But it has to be toplevel, not nested
down deep like standard drivers.

Larry

On 10/16/08, Andrew Francis <andrewfr_ice at yahoo.com> wrote:
>
> Hi Larry:
>
>
> --- On Wed, 10/15/08, Larry Dickson <ldickson at cuttedge.com> wrote:
>
>
> > I'm not sure I follow you here: the "mechanism that
> > waits for multiple inputs and selects one of them" certainly does not
> > look like a channel; it looks like a case statement.
>
> If I understand you correctly, I don't see a big difference (outside of
> less machinery) between
>
> val = stackless.receive_first([chan1, chan2, ....])
>
> and some construct, let us call it 'synchronizer' (loosely based on the van
> Aalst workflow pattern - synchronizer). Usually synchronizers are synonymous
> with barrier synchronization.
>
> val = synchronizer.wait(count) for N consumers, synchronizer.signal(some
> value) for the producers. In your case, you can wait for one.
>
> chances are channels would be implemented under the hood....
>
> If there is no consumer, a producer blocks. Once a synchronizer is
> triggered, future producers will raise an exception on a signal until the
> synchronizer is re-initialized.
>
> Again, I just feel that channels are powerful. However my limited
> experience has been that scenarios where a single consumer waits on multiple
> channels can be replaced with a simpler construct that is far more
> controllable (and use few channels).
>
> Cheers,
> Andrew
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20081017/68273f60/attachment.htm>