[Haskell-cafe] Re: Re[2]: Threading and FFI

2010-02-21 Thread Ben Franksen
Yves Parès wrote:
 Just one last remark: when I moved all my OpenGL calls from the main
 thread to an unbound thread. I thought it'd not work -- because I assumed
 I would have to launch it in a bound thread -- and however it went
 right...

You were just lucky the RTS accidentally delegated all your OpenGL calls to
the same OS thread. It might turn out bad next time you run the program, or
on another machine, or after adding more threads. Been there...

Cheers
Ben

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Re[2]: Threading and FFI

2010-02-21 Thread Lars Viklund

On 02/21/2010 09:51 PM, Ben Franksen wrote:

Yves Parès wrote:

Just one last remark: when I moved all my OpenGL calls from the main
thread to an unbound thread. I thought it'd not work -- because I assumed
I would have to launch it in a bound thread -- and however it went
right...


You were just lucky the RTS accidentally delegated all your OpenGL calls to
the same OS thread. It might turn out bad next time you run the program, or
on another machine, or after adding more threads. Been there...


I've been hacking on a DirectX binding recently where just about all 
calls have thread affinity as well.


The effect of running calls on the wrong thread there was (on my 
machine, running Seven) making the whole Windows GUI flicker. I wouldn't 
be surprised if it'd crash on other platforms.


Remember, undefined behaviour is not always kind enough to fail hard.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Re[2]: Threading and FFI

2010-02-18 Thread Ben Franksen
Yves Parès wrote:
 But there are two things that remain obscure:
 First, there is my situation: int the main thread, I call to some C
 functions binded through FFI. All of them are marked 'unsafe', except one,
 which is internally supposed to make pauses with 'usleep'.
 I then execute in another haskell thread (with forkIO) some pure haskell
 actions.
 I then compile with the threaded RTS, and let at run the default behaviour
 which is to use one core.
 
 Question 1) What happens to the unsafe C functions? I that simply that
 the threaded RTS is unable to prevent them from blocking haskell threads
 (which in my case is a problem only for the function which pauses, since
 other C calls are fast)?

Yes. unsafe FFI calls are executed just as a Haskell function. Thta means
the underlying OS thread that happens to run the Haskell thread which
contains the unsafe FFI call will block and thus all other activity that is
scheduled to be run by this OS thread.

Note: With unbound threads (those created by forkIO) it might happen at any
time that the RTS choses to reschedule your Haskell thread onto another OS
thread.

 Or they could provoke a hazardous issue, so I
 have to mark all the C functions as safe (which will be much slower)
 because ?

You can leave them unsafe if you are sure that

1) they do not call (back) any function in your program
2) they do not block (or not long enough that it bothers you)

Otherwise they are no less safe that the safe calls. If (1) is not
fulfilled bad things might (that is, probably will) happen. Thus, if you
are not sure, chose safe.

 Question 2) In the Control.Concurrent documentation, I understood that
 forkIO creates unbound threads whereas forkOS creates bound threads, but
 what is not very clear is: when does GHC threaded runtime launches as
 bound instead of unbound if this one has been started with forkIO? 

Never. Bound thread are ONLY needed if you (that is, some foreign functions
you use) rely on thread-local storage.

 When it
 detects the thread calls to a C function? When it detects it calls to a
 safe C function (*)? When it detects another thread calls to a (safe) C
 function (which is my case)?

In no case will forkIO create a bounded thread. Period. Bound threads are
created with forkOS.

If runtime is threaded and FFI call is marked safe and Haskell thread is
unbound, then calls to such a function will be executed from SOME extra OS
thread that is managed completely behind the scenes.

 (*) according to documentation it would be this case. However as I said my
 C calls are done in the MAIN thread. 

This doesn't make a difference. Main thread in Haskell is treated as any
other thread (except with regard to program termination; imagine it has an
invisible exit() call at the end).

 The other thread just executes casual
 haskell operations, however it is not blocked, which makes me think that
 even if I launch it with forkIO, it is launched as an bound thread.

No. Bound thread means something different. It means that Haskell (green)
thread is BOUND (fixed) to an OS thread. This is very bad for performance
and only serves one purpose: to enable interoperation with broken C
libraries (i.e. those which use thread local storage, a bad, bad, bad thing
IMVHO).

Cheers
Ben

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe