Hi Jeff, I think you make several good points...
On 10/17/08, Jeff Senn <[EMAIL PROTECTED]> 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 > [email protected] > http://www.stackless.com/mailman/listinfo/stackless >
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
