I'm having a look at the thread model at the moment. Here's the situation: ===============
Fibres (fthreads) can do blocking blocking ops. The fibres get shuttled off to the async queue and re-awakened when the op is complete. Examples: socket I/O and timer waits. Fibres can do schannel I/O. The fibres are descheduled and attached to the schannel until the transaction can be completed, at which time they're put back on the scheduler queue. Pthreads can do pchannel I/O. This is a full handshake data exchange by a monitor, it blocks the whole of a waiting pthread using OS condition variables. It makes no difference if the read or write is in a fibre. Pthread get their own private copy of the background event manager thread (demux), async wait queue, and scheduler queue. There is a job queue for thread pooling jobs, but no way to create such jobs from Felix. Fibres can't be rescheduled in another pthread (enforced by separation of the queues). There's also no sharing of I/O monitoring or timers. Fibres can't deadlock, pthreads can. What we want =========== I really expected pchannels to just block fibres. This could be done if the data transfer were mediated by the async queue, using svc_general, but at present the locking is all done in user space. I also assumed there was only one demux thread (background polling), and wondered how it rescheduled a job on the right queue. As far as I know it can actually do that right now, but I'm not sure (the queue management is rather complex). It would need a pointer to the scheduler object, and need to use a lock to put the fibre back on the queue. AFAICS the resched is done by the user thread. We really don't want multiple demux threads: that means every time you spawn a pthread you get two. It would also be good if writes to something, perhaps not a pchannel, but some other kind of channel, supported cross thread operations which blocked only fibres. It would also be nice to have a kind of fibre which could be scheduled on any pthread from a pool. Underneath all this, it would be nice if we had a type system which allowed the core spawn/channel I/O stuff to work more or less transparently. For example a type class. Should support processes as well. The idea would be: 1. You spawn a thread with particular environmental constraint eg same pthread, same process, or none.. Channels: strong synchronisation (current model), weak synchronisation (one object buffer), no synchronisation (buffered). Memory: shared, partly shared, explicit sharing only, no sharing. 2. And then when you do channel I/O, the type system picks the kind of channel you need. -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language