On 16/10/2010, at 2:34 AM, Rhythmic Fistman wrote: > > I also had some unclearness when I modified variables "above" the > fthread's closure (?). > Apple's "block" implementation makes outer variables read only, but fthreads > are > often synchronous (that's why I use them), so modification can work.
Yes, you can do sharing via "global" variables (that is, variables in a scope enclosing both fthreads, or accessed via a pointer). The only trick is that the actual order of execution is indeterminate (at present), and the control exchange points aren't well defined, but they're always in procedural code (i.e. at sequence points such as procedure calls). Functional code is never interrupted. >>> Tornado is basically >>> a "demuxer" (why did I call them that?) >> >> Because the os multiplexes asynchronous events into a queue, and your code >> takes the queue and unserialises it into interleaved thread execution.. :) > > Ah! I might rename it "event notifier" or something so people know what it does :) > >>> with a well wrapped lib curl. It's nice >>> to use, but it's still callback/event driven programming. Someone has hooked >>> it up to python generators (continuations?). Also, being python it's >>> single threaded - it seems >>> most folk just fork and hook it up a load balancer (nginx). >> >> >> Well Felix fthread are also running on a single CPU.. > > That's right, but tornado/python only offers you one logical thread, so you're > still passing your local variables from step to step. Actually it would be good to be able to run "fibres" on multiple CPUs. Of course this will happen if you use pthreads, but then you need mutex to do stuff, so the code is different (and it doesn't scale as well). Actually, as long as you use channels, it should be possible to make code that works in the same or different pthread to another code. That would require communication to be exclusively with channels. The channel semantics would be the same though. I think this can be done with a "demux", where the "notification event" is actually put into the queue by another thread. Of course .. this is what actual os threads do on a multi-core processor. Although AFAIK in Linux a thread always runs on the same CPU. [Called "affinity" ..] Anyhow to make this work I'd need a machine with "at least" 4 cores for testing. You'd basically run 4 copies of Felix, but with shared sleep queue. Probably the queue can be managed without locks too. -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
