FFI, safe vs unsafe

[Wolfgang Thaller]

John Meacham wrote (... but I've reordered things):

> My only real 'must-have' is that the 4 modes all can be explicitly and
> unambiguously specified. I have opinions on the syntax/hints but  
> that is
> more flexable.

I basically agree (the syntax discussion will take place in the years  
after the semantics discussion), but...

I want programmers to have a way of saying "this function might spend  
a lot of time in foreign lands". These calls should be concurrent on  
all implementations that support it (because some separately  
developed/maintained piece of Haskell code might expect to run a  
computation in the background), but if there are implementations that  
don't support it shouldn't flag an error, because that would  
encourage library writers to specify nonconcurrent when they can't  
prove that it's safe, or make code needlessly nonportable.
Another way to look at it: You cannot decide whether the call  
actually has to be done concurrently by just looking at the call site  
- you'd need to look at the entire program, and asking people  
(especially library writers) to state and guarantee global properties  
of a program that might not even be finished yet is a Bad Thing.  
Therefore, the concurrency annotation on the foreign import can only  
be a hint on whether the foreign function is guaranteed to return  
quickly or not; the actual requirement for the call to be  
"concurrent" is hidden in the other code that expects to run at the  
same time. Therefore, it would be wrong for an implementation that  
doesn't support concurrent calls (reentrant or nonreentrant, I don't  
care) to flag an error; the foreign import declaration correctly  
refuses to give a guarantee that the function will return quickly.  
The error is in the code that expects to run concurrently with a  
foreign import on an implementation that doesn't support that (but of  
course, a compiler can't detect such an error).

> Another nice minor thing would be if haskell implementations were
> required to ignore annotations starting with 'x-' for implementation
> specific hints.

Sounds good. Syntax discussion postponed again ('x-' looks so mime- 
typish. Could we add a meaningless 'application/' to the front? Just  
kidding).


> In my survey of when 'reentrant concurrent' was needed, I looked at  
> all
> the standard libraries and didn't find anywhere it was actually  
> needed.
> Are there some compelling examples of when it is really needed in a
> setting that doesn't have OS threads to begin with? (I am not  
> asserting
> they don't exist, I just want to see some example uses of this feature
> to get a better handle on the implementation cost)

In my experience, reentrant calls are rare in non-GUI code, but they  
become quite common in GUI code (OK, in some GUI libraries, there is  
only one, called something like RunMainEventLoop, but then it runs  
almost all of the time and is absolutely crucial). And with most GUI  
libraries, the GUI's main event loop will refuse to cooperate well  
with a Haskell's implementation's scheduler, so it will need to be  
called as a "concurrent" foreign import if your application is to do  
any background processing while waiting for events.
Other libraries that rely on callbacks would include the GLU  
Tesselator that I already mentioned, as well as several packages for  
solving optimisation problems. For those, concurrency would probably  
only become an issue when they are used with a GUI (even if it's only  
to display a progress bar).
Another reason why you don't see them in Haskell standard library  
code might be that everyone prefers Data.List.sort to foreign import  
ccall qsort.

> Any particular reason hugs and GHC didn't use the state-threads  
> approach
> out of curiosity? did it conflict with the push-enter model?  (jhc  
> uses
> the eval-apply model so I am more familier with that)

It was before my time. I guess it's because GHC uses a separate heap- 
allocated Haskell thread, so it made sense not to bother to allocate  
a separate C stack for every one of them. Don't know about Hugs.

> It also implys that a function call will run on the same OS thread as
> the OS thread the current haskell thread is running on.

This shouldn't be put into a standard, as the bound threads proposal  
already gives a different guarantee about that, and both guarantees  
taken together probably guarantee too much - taken together, they  
probably mean every Haskell thread has to be an OS thread. It might  
be an implementation-specific guarantee, unless the bound threads  
become a part of the standard in their entirety.

> 'OS thread the current haskell
> thread is running on' (GHC already doesn't when bound threads arn't  
> used
> I am led to believe?)

There should be no such thing as the 'OS thread the current haskell  
thread is running on' in any standard; OS thread identity is only  
observed through the FFI.

>  this means that things like 'log' and 'sin' and
> every basic operation goes through the FFI mechanism so it needs to be
> _fast_ _fast_. A neat side effect is that jhcs implementation of the
> prelude is mostly portable to different compilers.

I, too, want foreign import nonconcurrent nonreentrant to compile to  
a plain call without any extras. GHC achieves that goal, even in the  
presence of bound threads; I'm optimistic about jhc + state threads,  
too.

==== Bound Threads / Implementation methods ====

> I am not quite sure whether you are saying something different from  
> what
> I plan for jhc or not, my current thinking for jhc is,
> [...]
> An alternate mode I'd like to experiment with one day is the complete
> oposite side of the spectrum:
>
> one OS thread per haskell thread, no guarentees about duplicated work
> between threads.

Let me add a third one:
One OS thread per haskell thread, locks & condition variables used to  
make them behave just like state threads.
Creating threads and switching from one thread to another would be  
slower than with state threads by about the time it takes to do a  
trip to the kernel and back. Nonconcurrent foreign imports are just  
plain calls, concurrent foreign imports have to release the lock (and  
maybe signal another thread) and then re-acquire it afterwards.  
Foreign exports need to check whether the current OS thread owns the  
lock (TLS access), and wait for the lock if it doesn't.

And a fourth one:
Your "single true OS thread" runs all *unbound* Haskell threads and  
your scheduler (on separate stacks). Bound threads run in their own  
OS threads, and the scheduler will use OS thread primitives (foreign  
imported nonconcurrent) to run them and to wait for their time slice  
to finish (if you're doing preemption) or for them to block. It's  
like "if target thread is bound, use OS thread primitives, else use  
State Thread primitives to pass control to it". Foreign import  
nonconcurrent is a plain call. Foreign import concurrent from a bound  
thread releases the lock before calling (and waits for it  
afterwards). From an unbound thread you could implement it the way  
you planned to.
Call-ins would need that one stack pointer range check, and wait for  
a lock if it fails.


> well, the cost of bound threads is not the cost of the call itself, it
> is that they must be serialized. foreign concurrent calls can run
> concurrently to haskell code and each other. but 'bound' foreign calls
> must wait for their dedicated thread to become available. I think  
> there
> needs to be an annotation as to which functions require boundness so
> suddenly all foreign calls arn't serialized just because they are in a
> 'forkOS'ed thread.

I think you're mistaken here. For every given OS thread, *at most  
one* Haskell thread will ever be bound to it. So when you make a  
foreign call, you can be sure that the OS thread that is supposed to  
execute it is available *right now*, because the only Haskell thread  
that has the right to cause code to be executed in the bound OS  
thread has obviously finished any previous foreign calls. No need to  
wait. Ever.
In the bound threads proposal, the only basic method to create a  
bound thread is a call to a foreign export (or to main). The  
resulting thread of Haskell execution is bonund to the OS thread that  
made the call. The library function forkOS is just a call to  
pthread_create or it's Windows equivalent.
It would be possible to add an annotation to "foreign export" that  
states that "the Haskell thread that results from a call-in to this  
function does not need to be bound" (if that would improve  
performance), but back when "bound threads" were born we decided  
against it to keep things simple; instead, we added  
"runInUnboundThread :: IO a -> IO a" to keep the people who were  
concerned about performance happy, and I have yet to see it used by  
anyone.

>> ==== On the implementability of "concurrent reentrant" ====
>> [...] b) The runtime thread will need to periodically check  
>> whether an
>> interthread message has arrived, and if there is no work, block
>> waiting for it. The fast path of checking whether something has been
>> posted to the message queue is fast indeed - you just have to check a
>> global flag.

> I'd integrate it into the EDSM loop somehow (futex maybe) as I have a
> moral adversion for periodic checking of anything.

Yes, I was thinking of checking the flag just as a way to avoid  
calling epoll if a foreign call is already waiting. Basically, you'll  
want to write a message to a pipe so that it gets picked up by the  
EDSM loop. After all, a pipe is nothing but a traditional unix-style  
message queue :-).

> the main thing is that it is a cost paid by every foreign export.
> perhaps a flag saying "this will only be called nonconcurrently on
> exports" though, perhaps that can be an x-flag if other compilers  
> can't
> take advantage of it.

Yes, such an x-flag would be entirely reasonable if those few  
instructions for a stack pointer range test become significant. Those  
functions will, of course, be very rare.

> how prevelant is support for __thread BTW? is it required by any
> standards or an ELFism?

It is an ELFism by birth; __declspec(thread) is the equivalent  
MSVCism, and I don't know of any other equivalent features (but then  
my horizon doesn't extend much beyond the Mac/Linux/Windows triad). I  
hope that Apple and the mingw32 team soon implement it, too, but  
that's just an unfounded hope.



That's all for now,

Cheers,

Wolfgang