[Stackless] Stackless based replacement

Larry Dickson ldickson at cuttedge.com
Mon Oct 20 16:41:33 CEST 2008


Hi all,

Let me cross-reference the thread "Stackless IO ?" which sounds as if it is
relevant to this discussion (i.e. I wonder if they just did the same thing:
asynchronous IO and worker threads - I assume external to Stackless VM -
sound like it; can anyone comment?). As mentioned before, all you need is
select, which would not be restricted to Windows. However, Peter Welch, the
CSP theoretician, confirmed that many-to-many channels don't work properly
with ALT or select. This was on the occam-com list, and I will copy my
definition of a many-to-one channel that is capable of ALT, which I posted
there:

"For lack of a more authoritative many-to-one channel implementation, here
is the two-word one I thought of; N being NotProcess.p, R being
ProcessInputting, W[i] being ProcessOutputting[i] of a FIFO sequence which
gets consumed. Possible states are (N,N), (R,N), and (W[j],W[j+k]). W[j]
equals W[j+k] if and only if k=0, and the queue from W[j] to W[j+k] is a
subset of the processes for which the channel is simultaneously declared. An
unconditional channel input goes from (N,N) to (R,N), from (W[j],W[j]) to
(N,N), or from (W[j],W[j+k]) to (W[j+1],W[j+k]) if k>0. An input ALT enable
goes from (N,N) to (R,N) and Waiting.p, or from (W[j],W[j+k]) to
(W[j],W[j+k]) and Ready.p. An output goes from (R,N) and Waiting.p to
(W[j],W[j]) and Ready.p, and otherwise from (N,N) to (W[j],W[j]), from (R,N)
(unconditional input) to (N,N), or from (W[j],W[j+k]) to (W[j],W[j+k+1]).
The queue between W[j] and W[j+k] is a linked list in the W[i] process
workspaces much like a process queue."

So someone can check if "Stackless IO" is doing this. Two points: (1) I
forgot to mention (R,N) to (N,N) if the channel loses the ALT before a W
connects; (2) There was a mention somewhere in the "Stackless IO ?" thread
or the referenced blogs that it wasn't really stackless; the above is; and
it's possible (I don't know enough technical details to be sure) that
restricting the channel to one consumer (reader, inputter) is what is
needed.

Larry



On 10/17/08, Larry Dickson <ldickson at cuttedge.com> wrote:
>
> Hi Jeff,
>
> I think you make several good points...
>
> On 10/17/08, Jeff Senn <senn at maya.com> wrote:
>>
>> I've been vaguely watching this discussion -- and I think there might be a
>> bit
>> of a communication mismatch....  pardon me if I'm wrong -- I'm probably
>> not paying enough attention...but....
>>
>> Stackless was not really designed to be the "OS kernel layer" to a generic
>> everyone-writes-their-own-tasklets-they-all-run-together sort of system.
>
>
> And communicate at the top level via channels - that's what I thought, and
> that's why I have dived in.
>
> Stackless started as a sort of non-religious set of smallest changes to
>> C-Python to allow you to build  many such systems of different kinds.
>> (along lots of dimensions:  preemptive/cooperative,
>> coroutines/micro-thread,
>> resource-driven,  priority-managed,  arbitrary generator,
>> producer/consumer etc...)
>
>
> Find your own subset sounds like a good idea, if the underlying structure
> is completely general. I do notice people complaining about sockets blocking
> all the tasklets, etc, so maybe a little work still needs to be done.
>
> So, Larry, I think if you say "I want Stackless to be X" -- the folks on
>> this list are vaguely going to think... "well it can already do that; you
>> just need to write some python code and then standardize on it",
>> and you would respond (somewhat correctly): "Well, *that* isn't
>> very user-friendly; nor is it a very good  architecture!"
>
>
> But if the good architecture can be expressed in it, then that is OK.
>
> Stackless does sort of suffer, in explanation, by not having a
>> *standard* and *prominent* more abstract layer...
>> very early on there was a "uthread" module that was such a thing...
>> now there are lots of different "demos" floating around...
>
>
> I like demos, as they become templates - i.e. you take the source (short, I
> hope) of the demos, insert your own code, and just keep on going from there.
> All that is needed is to make the foundation capable of supporting the
> desired demo. For what I have in mind, a flavor is needed that: (A) is
> capable of declaring one-to-one and many-output-to-one-input channels (the
> current code, or at least its comments, offer only many-to-many); (B) is
> capable of declaring one-sided channels (or some equivalent, that responds
> to "hardware" IO like those external sockets) - and of course following (A)
> if input it has to be capable of restricting it to a "to one" input (I think
> that is what everybody already does anyway in real life); (C) has some kind
> of linker that allows you to hook up multiple programs, so that one's
> outputs connect to the other's inputs - literally fitting your
> "everyone-writes-their-own-tasklets-they-all-run-together" ideal using a
> load-time script. I did stuff like this in DOS scripts in 1995, but all in
> assembly, not being up to writing a compiler :-(.
>
> Larry
>
> -Jas
>>
>> On Oct 17, 2008, at 10:33 AM, Larry Dickson wrote:
>>
>> 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
>>>
>>
>> _______________________________________________
>> Stackless mailing list
>> Stackless at stackless.com
>> http://www.stackless.com/mailman/listinfo/stackless
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20081020/114bd7e2/attachment.htm>


More information about the Stackless mailing list