daanleijen at xs4all.nl
Fri Mar 21 08:32:53 EST 2003
> I think everyone is keen to make progress on this bound-threads stuff.
> You have an alternative idea which we are trying to understand. Do you
> plan to have a go at the operational semantics, as a way of explaining
Sorry for not having replied. I am very busy finishing my thesis and I can't
look into it sooner than next week. The thesis-finishing business is in
any case taking so much time that I can't really help out on implementation
or other time consuming activities.
However, my proposal is not anywhere fundamentally difficult -- in its essence, I just propose to move the implementation of the thread allocation strategy from the RTS/C code, to a Haskell library. This gives programmers both a low-level interface for explicit access and a high-level interface as it is now.
> At the moment we're a bit stuck: no one wants to move on before we
> have some kind of consensus, but you're the only one who can help us
> understand your proposal.
Well, it is not my intention to stop progress! I haven't fully worked out my design, for example, it seems that dynamic rescheduling of haskell threads to OS threads is rather difficult -- I can only say more about this next week.
What I mostly wanted to ensure is that people have really thought about this carefully and that they could give strong reasons for choosing a particular design over another. If you feel that this is the case -- by all means continue as you have done and disregard my disturbances.
All the best,
> | -----Original Message-----
> | From: Simon Peyton-Jones [mailto:simonpj at microsoft.com]
> | Sent: 17 March 2003 22:06
> | To: Daan Leijen; Wolfgang Thaller; ffi at haskell.org
> | Subject: RE: Bound Threads
> | | | | | 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.
> | | | Daan,
> | | There has been extended discussion on this stuff, which Wolfgang and
> | Simon and I tried to boil out into a document. It's hard to say
> | what 'safe' or 'bound' exports, or whatever, might mean, so we give a
> | little operational semantics.
> | | My hope is that the very same operational-semantic framework would
> | to describe your system. Would you like to write its transition rules,
> | in the same style? Then we could compare the two more easily.
> | that, I am hard pressed to understand the implications of what you
> | suggest, just as I was hard pressed to understand Wolfgang's proposal
> | till we had it specified.
> | | You can find the document in the CVS respository in
> | haskell-report/ffi/threads.tex
> | | Simon
More information about the FFI