Re: Native Threads in the RTS

[Wolfgang Thaller]

So, we can say that foreign functions of the form:

  foreign import bound unsafe bar :: ...

are illegal or we can allow them and provide warnings or we can allow
them and trust the programmer to know that bar is much more expensive
than they think.  (I favour the first two.)

NOOO! Don't do that! Please don't!

I see two potential problems with this (but would like to hear which,
if either, dominates your thoughts):

1) If foreign threads cannot be used to execute Haskell code, foreign
   calls require (OS-level) context switches which are expensive.

2) Adding an implicit lock to foreign calls might surprise programmers.

I'm slightly concerned about 2), but 1) Is an absolute show-stopper for me.

It should stay possible to implement an unsafe call as just a call - no special RTS management, no context switches, no nothing, just a few machine code instructions to move the parameters to the stack and/or registers.
And I definitely do want to keep that efficiency for "bound" Haskell threads.
The reason why I startet this discussion is that I want to use OpenGL in my Haskell Programs (which works fine with GHC's current non-threaded RTS). OpenGL requires a lot of calls to functions that don't take much time to execute and that don't call back to haskell land. Using "safe" or even "threadsafe" for these calls would kill performance utterly and completely.

*) Exactly one Haskell thread associated with the native thread is
executing. All other associated Haskell threads are blocked. No
foreign code is being executed by the native thread.

This isn't quite right - or, at least, needs clarified.

Consider Haskell functions a,b,c,d and C functions A,B,C,D and a call
pattern

  a -> A -> b -> B -> c -> C -> d -> D

That is, a calls A, calls b, calls B, calls ...

Suppose we want A,B,C,D executed by the same foreign thread.

[...]

I think the quoted text assumes that a,b,c,d are blocked during the
call to D.

Yes. For the purpose of the above paragraph (and the neighboring paragraphs in the spec), a Haskell thread is considered "blocked" during a call to a foreign imported function. I admit that this terminology is inspired by implementation details of GHC, but it makes [some] sense: After all, if there is no Haskell code to execute [it's foreign code only now], the Haskell thread can not be executed. A Haskell thread can be either blocked or executing Haskell code.

This needs careful interpretation if we want to be able to bind
finalizers to foreign threads.  In particular, if a finalizer is bound
to a foreign thread, we don't increment 'bindees(f)' until the
finalizer starts and we don't start the finalizer unless either:

I'm not currently planning to allow finalizers to be bound to native(foreign) threads, as I have so far failed to see a solution that I'm happy with.

[...] From an implementation point of view, this requires:

1) That foreign threads are _not_ used to execute Haskell code.

One of my design goals is to allow the native threads to be used to execute Haskell code. Implementations are not required to do so, but it should be possible.
For that reason I also dislike the term "foreign thread". It sounds great until I want to say "the implementation may use the foreign thread to execute Haskell code".

....
And just as I went back to the computer after a long pause in order to finish this message, a new proposal arrived. I'll take more time to study it more completely. I just want to reiterate one thing:

The notion of bound foreign imports could be eliminated by saying that
all foreign calls are performed by the bound thread if one exists and
eliminate the concept of 'bound foreign imports'.  The only reason to
allow any flexibility is to allow for faster implementations which
perform less context switching - this is especially important for
'unsafe' foreign calls.

I definitely need zero-overhead bound unsafe calls. Everything else would be basically unusable for me.

I'll be back later.

Cheers,

Wolfgang

_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users