Michael Hobbs <[EMAIL PROTECTED]> wrote,
> "Manuel M. T. Chakravarty" wrote:
>
> > Following the reverse naming scheme of the FFI paper:
> >
> > unsafe - the RTS makes no special provisions and just
> > calls the C function (this means the function
> > must be well-behaved: no re-entry into the
> > Haskell scheduler and no blocking if you
> > don't want to block the whole Haskell system)
> > safe - the RTS cleans things up, to allow the called
> > function to re-enter the Haskell scheduler (but
> > if the function blocks, the whole Haskell
> > evaluation still blocks)
> > threadsafe - the RTS executes the foreign call in a
> > (or supersafe) seperate OS thread (the function can do what
> > it likes)
> >
> > The label does NOT describe a property of the function, but
> > it describes the strategy of the RTS. For "safe" calls, the
> > RTS plays safe, for "threadsafe" calls it plays supersafe.
>
> So what you have is increasing levels of "safety"? The first one is
> completely unsafe; it could royally screw up the RTS if it invoked a
> Haskell callback. The second is more safe; but it may cause the entire
> RTS to block. And the third is completely safe; nothing it can do will
> affect the Haskell RTS (within reason).
Exactly.
> This works for me, as long as I can still get barrier synchronization
> like we [Manuel and myself] discussed earlier, but that's another issue.
> I do think that the use of the word, "safe", is unfortunate though. It
> seems to be too overloaded.
I am also not too happy about this choice of names. I had
to do it at least two times wrong until this naming scheme
sticked to my mind. It is just too tempting to regard
"safe" as a property of the function and not the calling
mechanism.
Re barrier sync: I think, the method of using a combination
of unsafePerformIO and standard semaphores from
`Concurrent', as outlined by Sven Panne, should do the job.
I'll also try to put the new thread-related functions of
GTK+ 1.2 into the binding soon.
Michael, do you read the GTK+ mailing list? If not, mail me
privately and I'll forward you some very recent interesting
comments on multi-threaded applications.
Manuel
