Bound Threads

[Daan Leijen]

Hi Wolfgang,

I feel like you are beating my proposal to death here, and I find it hard to
react individually to all your remarks. I'll try to focus on the main issue:

You are worried that the forkOS and forkIO distinction is too primitive and
that it rule out sophisticated scheduling on SMP processors for example.
I think that you are right if the programmer use forkOS and forkIO directly
all the time but in general, we can provide abstractions *in haskell* to deal
with scheduling. See my "fork" example in the previous mail.

The bottom line is that if we have access from Haskell to the primitives, we
can always implement any smart scheme that we need or want. If you implement a strategy via keywords, it is fixed. I don't promote using low-level programming
but I think that "bound" and "threadsafe" should be implemented using combinators
in Haskell itself, with some low-level functions like forkIO.

Maybe, the forkOS/forkIO approach is flawed, but I think we should
only rule it out when we can provide a convincing example where only
the keyword approach would work, and where we can't use combinators to
achieve the same effect.

All the best,
  Daan.


About the example:

>> Now, I have an example from the wxHaskell GUI library that exposes some
>> of the problems with multiple threads. I can't say it can be solved
>> nicely with forkOS, so I wonder how it would work out with "threadsafe":
>
> [snip]
> In case that wxWindows makes the assumption that it's functions are invoked _from the same OS thread_ that it used to call your callback, you can add "bound" to the foreign export statement for your callback.
>
> Then you would use just forkIO and everything would work.

That is amazing :-) Suppose that there is one OS thread running here -- the GUI thread. When the callback is called, I use "bound" so that the callback still runs in the GUI
thread. When I use "forkIO", the forked computation could also run in the same GUI thread
(I guess it is unspecified, but suppose it does). When the callback returns to C land,
the eventloop will wait and since there is still just one OS thread running, the
forked computation will block.... Urk, somehow the RTS has to be smart enough to spawn
a new OS thread when forkIO is called. Right?

>> Since the haskell function is called via a callback, I guess that "threadsafe"
>> should also apply to "wrapper" functions -- that is, when the foreign world
>> calls haskell, we use another OS thread to run the haskell code.
>
> Sorry, no clue what you mean... could you elaborate? "threadsafe" just applies to imports, not to ? exports and wrappers. "bound" applies to exports and wrappers, but not to imports. Should it be different?

Since the RTS can't guess whether to use new OS threads or not at forkIO, I assumed
that you could mark "wrapper" functions (callbacks) with a "threadsafe" attribute. If
this is not the case, I don't understand how the implementation could work in this particular
example.