some kind of consensus, but you're the only one who can help us
understand your proposal.
Simon
| -Original Message-
| From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]
| Sent: 17 March 2003 22:06
| To: Daan Leijen; Wolfgang Thaller; [EMAIL PROTECTED]
| 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
| Now, what I don't like about my proposal and your proposal is
| that the user has to be aware of OS threads when making
| foreign calls by wrapping it in threadSafe or adding
| threadsafe sometimes -- but maybe that is unavoidable.
Actually, the proposal currently on the table, which no one
Hi Daan everyone else,
Now, I can be easily convinced that threadsafe is the way to go,
whenever there
is a compelling example where forkOS/forkIO fails.
I'm not arguing that there is a situation where forkOS/forkIO fail to
provide sufficient functionality. In fact, I'm afraid they may provide
For what it is worth I favour Daan's approach, adding keywords to a language
seems to want for a sufficiently rich formalism/framework.
3) maybe we should also add forkUnbound that forks a haskell thread
that can automatically be moved between OS threads.
In the spirit of searching for the
Hi all,
I have just spend some time reading through all the discussions and the
new threads document and I would like to propose the addition of a new library
function.
forkOS :: IO () - IO ThreadID
The function forkOS forks a new Haskell thread that runs in a new OS (or
native) thread. With
Hi Simon,
I'd like to point out a concept that I think is being missed here:
We never want to specify what OS thread is running a particular
Haskell thread.
why not? Because (a) it doesn't matter: the programmer can never tell,
and (b) we want to give the implementation freedom to spread
I have just spend some time reading through all the discussions and the
new threads document and I would like to propose the addition of a
new library function.
forkOS :: IO () - IO ThreadID
Something like that is already in the proposal, only it's currently
called forkBoundThread and it
In general, I think that only the programmer knows what strategy to
use.
Do programmers know? I know about my own program, but do I know about
the library that I am going to use? Does it use forkOS or forkIO? What
will be the consequences if it uses forkIO and I do a lengthy foreign
call?
Does
(I keep forgetting to correctly fill out the To: and Cc: fields before
sending my reply... so here's the copy that should have been sent to
the list 10 minutes ago...)
Daan Leijen wrote:
Hi Wolfgang,
I feel like you are beating my proposal to death here, and I find it
hard to
react
Alastair Reid wrote:
Does anyone plan to add support for multiple OS threads to Hugs or
NHC?
I think it will depend a bit on the complexity so let me sketch how I
think it can be implemented.
First let me outline my current understanding of what 'bound' means.
Consider the following scenario:
Does anyone plan to add support for multiple OS threads to Hugs or NHC?
I think it will depend a bit on the complexity so let me sketch how I
think it can be implemented.
First let me outline my current understanding of what 'bound' means.
Consider the following scenario:
Haskell program is
Simon Peyton-Jones wrote:
[I've updated the Semantics for foreign threads document by
re-ordering the sections a bit. It'd benefit from having a bit more
formal syntax.
That should be just a matter of copying from the ffi spec and adding an
additional specialid... I had hoped to avoid learning
I just skimmed over Wolfgang's PDF and things look quite reasonable.
Just to make sure I have understood everything correctly: To make
HOpenGL work in the presence of a threaded RTS, the only places which
need a change are the stub factories for GLUT callbacks, where a bound
attribute is required
Sven Panne wrote:
Just to make sure I have understood everything correctly: To make
HOpenGL work in the presence of a threaded RTS, the only places which
need a change are the stub factories for GLUT callbacks, where a
bound
attribute is required now.
Correct.
What about the foreign import of
15 matches
Mail list logo
