Yesterday evening I was experimenting with an electronic circuit, and the fumes from the soldering must have entered my brain and triggered something there - I've thought up a new proposal, which I like much better than the old one. It no longer requires extending the FFI syntax; instead, it uses just one new combinator. It can be implemented as efficiently as the previous proposal. The proposal is described in detail in the new "Part II" of the haskell-report/ffi/threads.tex document (in CVS). For everyone's convenience, I've put up a typesetted version again at:
http://www.uni-graz.at/imawww/haskell/threads.pdf
Everyone please tell me what you think.
I've not had the benefit of soldering fumes, but I find whiteboard markers work quite well ;-) I think I like it. Just to clarify: when you fork a new Haskell thread, it isn't associated with a native thread, right? (the semantics doesn't model forkIO, I think it probably should). If true, that gives us the important principle that At any one time, there is at most one runnable Haskell thread associated with, or bound to, any given native thread. which is important for reducing the complexity of the implementation. In an implementation which actually runs the Haskell thread in its bound native thread (eg. GHC), we can be sure that when we want to switch to the bound native thread it isn't off doing something else. Is that the reason for wanting this property? Cheers, Simon