[Stackless] Stackless based replacement

[Larry Dickson]

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/20081017/71f05bd5/attachment.htm>