<div>Hi Jeff,</div>
<div>&nbsp;</div>
<div>I think you make several good points...<br>&nbsp;</div>
<div><span class="gmail_quote">On 10/17/08, <b class="gmail_sendername">Jeff Senn</b> &lt;<a href="mailto:senn@maya.com">senn@maya.com</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I&#39;ve been vaguely watching this discussion -- and I think there might be a bit<br>of a communication mismatch.... &nbsp;pardon me if I&#39;m wrong -- I&#39;m probably<br>
not paying enough attention...but....<br><br>Stackless was not really designed to be the &quot;OS kernel layer&quot; to a generic<br>everyone-writes-their-own-tasklets-they-all-run-together sort of system.</blockquote>
<div>&nbsp;</div>
<div>And communicate at the top level via channels - that&#39;s what I thought, and that&#39;s why I have dived in.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Stackless started as a sort of non-religious set of smallest changes to<br>C-Python to allow you to build &nbsp;many such systems of different kinds.<br>
(along lots of dimensions: &nbsp;preemptive/cooperative, coroutines/micro-thread,<br>resource-driven, &nbsp;priority-managed, &nbsp;arbitrary generator, producer/consumer etc...)</blockquote>
<div>&nbsp;</div>
<div>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.</div>
<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">So, Larry, I think if you say &quot;I want Stackless to be X&quot; -- the folks on<br>this list are vaguely going to think... &quot;well it can already do that; you<br>
just need to write some python code and then standardize on it&quot;,<br>and you would respond (somewhat correctly): &quot;Well, *that* isn&#39;t<br>very user-friendly; nor is it a very good &nbsp;architecture!&quot;</blockquote>

<div>&nbsp;</div>
<div>But if the good architecture can be expressed in it, then that is OK.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Stackless does sort of suffer, in explanation, by not having a<br>*standard* and *prominent* more abstract layer...<br>
very early on there was a &quot;uthread&quot; module that was such a thing...<br>now there are lots of different &quot;demos&quot; floating around...</blockquote>
<div>&nbsp;</div>
<div>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 &quot;hardware&quot; IO like those external sockets) - and of course following (A) if input it has to be capable of restricting it to a &quot;to one&quot; 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&#39;s outputs connect to the other&#39;s inputs - literally fitting your &quot;everyone-writes-their-own-tasklets-they-all-run-together&quot; ideal using a load-time script. I did stuff like this in DOS scripts&nbsp;in 1995, but all in assembly,&nbsp;not being up to writing a&nbsp;compiler :-(.</div>

<div>&nbsp;</div>
<div>Larry</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">-Jas<span class="q"><br><br>On Oct 17, 2008, at 10:33 AM, Larry Dickson wrote:<br><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Andrew,<br><br>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?)<br>
<br>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.<br>
<br>Larry<br></blockquote><br></span>
<div><span class="e" id="q_11d0b74efd555c02_2">_______________________________________________<br>Stackless mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Stackless@stackless.com" target="_blank">Stackless@stackless.com</a><br>
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.stackless.com/mailman/listinfo/stackless" target="_blank">http://www.stackless.com/mailman/listinfo/stackless</a><br></span></div></blockquote></div>
<br>