| I think the essence of Daan's proposal was that the goals we hope to
| achieve using 'bound', 'threadsafe', and other ffi annotations could
| be achieved by adding a small amount of additional functionality
| and wrappers and that benefits of doing this are:
That all sounds splendid. If only I u
Daan writes:
> 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.
SimonPJ replies:
> The difficulty is that I can't give strong reasons for choosing X
> over Y when I don
| 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 inte
ces.
All the best,
Daan.
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
|
have 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: Bou
| 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 o
| 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 st
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 provi
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 Wolfgang,
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.
That's unfair ;-) --- I could also claim the reverse
(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 individ
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 proces
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 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 does
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 Haskell
> 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
> nat
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
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:
| First let me outline my current understanding of what 'bound' means.
| Consider the following scenario:
|
| Haskell program is running in OS thread 't1'
| Haskell program calls C function 'foo'.
| 'foo' forks a new OS thread 't2'.
| In parallel: 't1' calls Haskell function 'f1' and
|
> 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'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. No one has commented a single word on the operational
semantics. I don't know whether that's because it's so clear that no
discussion is needed, or so
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
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
24 matches
Mail list logo
