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 <[EMAIL PROTECTED]> wrote: > > 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
