> This sounds like a lot of work and a porting nightmare (what do you
> mean Linux/Win32/HPUX/... doesn't have thread manipulation function X,
> it's available on FreeBSD/Win32/... What if there are other forms
> of thread-local state (e.g., errno)? What about setjmp/longjmp?).
Yes, these are all problems. However, there is a nice abstraction of
the OS thread API in GHC's RTS, thanks to Sigbjorn. So I'm sure this
API could be extended to include some thread-local state operations.
> The only viable solution I can see is to provide a way to capture the
> calling thread (as a first class entity) when you call into Haskell
> and to explicitly specify whcih thread to use when you call out from
> Haskell. (Hmmm, sounds like callcc for C :-))
The trouble is, that is *way* too much overhead for a C call. HOpenGL
does lots of these, and I strongly suspect that adding a full OS-thread
context switch (well two, including the return) for each one would be a
killer.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
