| 2. Calling from foreign code into Haskell to a bound foreign import will | require some special handling to ensure that a subsequent call out to | foreign code will use the same native thread. Why couldn't this special | handling select the same Haskell thread instead of creating a new one?
This is just an efficiency issue, right? If creating a Haskell thread from scratch is very cheap, then it's easier to do that each time rather than to try to find the carcass of a completed Haskell thread. If you do the latter, you need to get into carcass management.
But maybe there is more to it than efficiency in your mind?
To recap, the suggestion was that a Haskell thread which makes a foreign call, which is turn calls back into Haskell, should use the same Haskell thread for the callback. So the Haskell thread is not a carcass, it is still running, but blocked waiting for the result of the foreign call. I'm not sure I've quite got my head around all the implications of doing this, but it sounds possible. However, I'm not completely convinced it's desirable: the gain seems to be in efficiency only, and a fairly small one (creating threads is quite cheap). I imagine you could demonstrate a performance gain by doing this for an application which does a lot of callbacks, though. The current situation has the advantage of simplicity: * for each 'foreign export' we create a single Haskell thread which lives until completion of the IO action. We can consider a standalone program as a call to 'foreign export main :: IO a' from a simple C wrapper (in fact, that's almost exactly how it works). Cheers, Simon