I've been watching the discussion about native threads, and getting
thoroughly confused.
Understandable ;-) .
But before investing effort in fiddling with it, I thought it'd be good
to see whether anyone finds it helpful.
Yes, it does seem to be a good idea.
Feel free to modify it. E.g. ad
| I've postponed writing up a new proposal again...
|
| But I'm going to sum up some requirements that I would like to see
| fulfilled - to make it clearer to others why I'm proposing such
strange
| things...
I've been watching the discussion about native threads, and getting
thoroughly confused.
Dean Herrington wrote:
[...] Rather, I find it
nonintuitive that calling from Haskell to foreign code and back into
Haskell
should create a new Haskell thread, when these two Haskell threads
really
are just different portions of a single "thread of computation"
(deliberately vague term).
I agr
> 2. It seems perfectly reasonable to want to have the Haskell
> called-back code throw an exception that is caught by the Haskell code
> that called out to foreign code. "Reusing" the Haskell thread is
> necessary (though not sufficient) to achieve such behavior.
This is a particularly trick
I've postponed writing up a new proposal again...
But I'm going to sum up some requirements that I would like to see
fulfilled - to make it clearer to others why I'm proposing such strange
things...
*) It should be possible for Haskell code to arrange that a sequence of
calls to a given librar
Simon Marlow wrote:
> > | 2. Calling from foreign code into Haskell to a bound foreign import
> > will
> > | require some special handling to ensure that a subsequent
> > call out to
> > | foreign code will use the same native thread. Why couldn't this
> > special
> > | handling select the same H
> | 2. Calling from foreign code into Haskell to a bound foreign import
> will
> | require some special handling to ensure that a subsequent
> call out to
> | foreign code will use the same native thread. Why couldn't this
> special
> | handling select the same Haskell thread instead of creating
| 2. Calling from foreign code into Haskell to a bound foreign import
will
| require some special handling to ensure that a subsequent call out to
| foreign code will use the same native thread. Why couldn't this
special
| handling select the same Haskell thread instead of creating a new one?
Thi
On 29 Nov 2002, Alastair Reid wrote:
> Consider Haskell functions a,b,c,d and C functions A,B,C,D and a call
> pattern
>
> a -> A -> b -> B -> c -> C -> d -> D
>
> That is, a calls A, calls b, calls B, calls ...
>
> Suppose we want A,B,C,D executed by the same foreign thread.
>
> Each of a,b
So, we can say that foreign functions of the form:
foreign import bound unsafe bar :: ...
are illegal or we can allow them and provide warnings or we can allow
them and trust the programmer to know that bar is much more expensive
than they think. (I favour the first two.)
NOOO! Don't do that
> > This is all getting highly confusing, as it seems we're working with
> > different ideas of what's on the table. Alastair: you seem to be
> > working on your own proposal - could you write it down either as a
> > complete proposal or diffs to Wolfgangs?
>
> I did. You sent comments on it an
> This is all getting highly confusing, as it seems we're working with
> different ideas of what's on the table. Alastair: you seem to be
> working on your own proposal - could you write it down either as a
> complete proposal or diffs to Wolfgangs?
I did. You sent comments on it and I sent bac
> Simon Marlow:
>
> > Another problem, from an implementation point of view, is that we
> > would have to surround "unsafe" foreign calls with a lot of
> > context-switching gumph, in case the calling Haskell thread is bound
> > to a native thread. I really think we don't want to do this.
>
> No
Simon Marlow:
> Another problem, from an implementation point of view, is that we
> would have to surround "unsafe" foreign calls with a lot of
> context-switching gumph, in case the calling Haskell thread is bound
> to a native thread. I really think we don't want to do this.
Note that you onl
> Or, we can adopt a much weaker semantics than Wolfgang
> intended and have:
>
> $0 <= bindees(f) - uses(f)$
>
> This would allow several currently running, active Haskell threads to
> all be bound to the same foreign thread. When any of these threads
> makes a foreign call, the other thre
[Note: I'm consistently using 'foreign thread' instead of 'native
thread'. The Haskell-spec necessarily treats Haskell as the centre of
the universe. So what a Linux kernel hacker might think of as a
'native thread' is really quite foreign to Haskell. Feel free to
ignore this little experiment
I'll write up a new version of the proposal tomorrow. For now, here are
some answers and [at the end] a question about the current FFI
specification.
Simon Peyton Jones wrote:
You don't say (but you do mean)
A bound Haskell thread can be executed only by its associated
native thread
No I don
Simon P.J. writes:
> Can you give an example of when a native thread is associated
> with more than one Haskell thread?
I gave an example in my previous message. It's when a bound Haskell
thread makes a foreign call which re-enters Haskell via a bound foreign
export.
> You don't say (and I'm no
Improving. Want to put it in CVS? Simon M can suggest where.
Simon
| Definitions
| ~~~
| A native thread (aka OS thread) is a thread as defined by the
operating
| system.
| A Haskell thread is [*** FIXME - How shall I put this? ***] the thing
| you see from Haskell land.
A "Haskell t
Simon Marlow wrote:
I don't see the problem with forking a new Haskell thread for each
foreign export, and associating it with the current native thread if
the
foreign export is marked "bound". It does mean we can get multiple
Haskell threads bound to the same native thread, but only one can be
> Are you sure you intend to change the type of forkIO? Currently it's
> forkIO :: IO () -> IO ThreadId
Sorry, no, I did not.
--
Alastair
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskel
> When a "bound" foreign exported function is invoked [by
> foreign code],
> the implementation checks whether a Haskell thread is associated with
> the current OS thread.
> If there is one, this Haskell thread is used to execute the callback.
> If there is none, a new Haskell thread is created
| Nice design, Alastair. I've stolen lots of ideas and some text for the
| complete rewrite of the proposal.
I think it is a great idea to rewrite the proposal. A tiny minority
will follow the details of the discussion, and it's essential to record
the outcome in a way comprehensible by someone w
Typo:
> Being fresh to Haskell, I suggest that the naming continues to be
> "native" and "free".
I did mean "native" and "green"
Have a nice day, once again.
Johan Steunenberg
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell
Nice design, Alastair. I've stolen lots of ideas and some text for the
complete rewrite of the proposal. The concept of "associating" haskell
threads to native threads proved to be a good way of explaining my
original idea in a different way --- and then I found out that
forkNativeThread needn'
At 2002-11-26 09:37, Alastair Reid wrote:
> 1) forkNativeThread :: IO () -> IO ()
> The fresh Haskell thread is bound to a fresh native thread.
>
> 2) forkIO :: IO () -> IO ()
> The fresh Haskell thread is not bound to a native thread.
Are you sure you intend to change the type of forkI
On 26 Nov 2002, Alastair Reid wrote:
> > Umm, Alastair, I think you've got things a bit mixed up here. Did
> > you mean two ways to create a native thread?
>
> No.
>
> > There are currently three ways to create a Haskell thread (forkIO,
> > foreign export, finalizers) and Wolfgang has proposed
> Umm, Alastair, I think you've got things a bit mixed up here. Did
> you mean two ways to create a native thread?
No.
> There are currently three ways to create a Haskell thread (forkIO,
> foreign export, finalizers) and Wolfgang has proposed a fourth
> (forkNativeThread).
I was (implicitly)
> *
> Native Threads Proposal, version 2
>
> Some "foreign" libraries (for example OpenGL) rely on a mechanism
> called thread-local storage. The meaning of an OpenGL call therefore
> usually depends on which OS thread it is called from.
> Therefore, some
> kind of direct ma
On Tue, 2002-11-26 at 08:32, Dean Herington wrote:
> On 26 Nov 2002, Alastair Reid wrote:
>
> > ps Better names than 'native' and 'green' surely exist. Something
> > which conveys the idea that the thread will be remembered for later
> > use seems appropriate but no good words spring to mind.
>
Alastair Reid wrote:
> Design
> ~~
>
> Haskell threads may be associated at thread creation time with either
> zero or one native threads. There are only two ways to create Haskell
> threads so there are two cases to consider:
Umm, Alastair, I think you've got things a bit mixed up here. Di
On 26 Nov 2002, Alastair Reid wrote:
> ps Better names than 'native' and 'green' surely exist. Something
> which conveys the idea that the thread will be remembered for later
> use seems appropriate but no good words spring to mind.
Perhaps "bound" and "free"?
_
After sending this mail this morning, I realized that threadsafety is
largely orthogonal to the choice of which thread to run in. For
example, I might want to make an 'unsafe' call in a particular native
thread.
So my proposed spec should add a second, orthogonal choice of ffi call
types ('nativ
After writing a fairly long, detailed reply (attached at end), I
decided it would be simpler to write my take on what the design should
be.
Goals
~
Since foreign libraries sometimes exploit thread local state, it is
necessary to provide some control over which thread is used to execute
fore
Nicolas Oury <[EMAIL PROTECTED]> writes:
> * I think that, if it is not too much complicated, it could be great
> to put many threads in the OpenGL OS thread. The goal of concurrent
> Haskell was to allow concurrency for expressivity. It would be a
> pity to lose this in part of programs for tech
Nicolas Oury a écrit:
* I think that, if it is not too much complicated, it could be great
to put many threads in the OpenGL OS thread. The goal of concurrent
Haskell was to allow concurrency for expressivity. It would be a pity
to lose this in part of programs for technical reason. Having thi
Hello,
I read your proposal. It's great but I have a few remarks :
* I think that, if it is not too much complicated, it could be great to
put many threads in the OpenGL OS thread. The goal of concurrent Haskell
was to allow concurrency for expressivity. It would be a pity to lose
this in part
Great, thanks. I hope you'll keep it up to date so that by the time
the
discussion converges it can serve as a specification and rationale. We
can put it in CVS too... Simon will think of where!
Until then, I'll play the role of a "human CVS server".
Ultimately it'd be
worth integrating with
| I've now written up a slightly more formal proposal for native
threads.
| (OK, it's only a tiny bit more formal...)
| I doubt I have explained everything clearly, please tell me which
| points are unclear. And of course please tell me what you like/don't
| like about it.
Great, thanks. I hope y
I've now written up a slightly more formal proposal for native threads.
(OK, it's only a tiny bit more formal...)
I doubt I have explained everything clearly, please tell me which
points are unclear. And of course please tell me what you like/don't
like about it.
I have some rough ideas on how t
Hello,
Le mardi 19 novembre 2002, à 01:28 , Wolfgang Thaller a écrit :
Nicolas Oury wrote:
I don't know if what I say is pertinent, but there was another problem
that was discussed in the thread about threaded RTS.
One may want to use a finalizer in a particular thread.
For example, a finalize
Nicolas Oury wrote:
I don't know if what I say is pertinent, but there was another problem
that was discussed in the thread about threaded RTS.
One may want to use a finalizer in a particular thread.
For example, a finalizer that put make a rotating cube on screen must
be ran in the same thread
I don't know if it is planned but I think it could be great to be able
to have, in the new OS thread for OpenGL, an "expressivity only"
concurrence system. I mean that to be able to fork user threads that are
executed in the new OS thread. These new threads would be blocked on
other threads in
I don't know if what I say is pertinent, but there was another problem
that was discussed in the thread about threaded RTS.
One may want to use a finalizer in a particular thread.
For example, a finalizer that put make a rotating cube on screen must be
ran in the same thread as the Opengl/GLUT th
> We can't currently allow several Haskell threads to really run
> simultaneosly [e.g. on two separate processors, or preemtively
> scheduled on a single processor], because they always mutate the same
> global heap. Currently, GHC switches its green threads only at times
> when the heap is in
> I'm still unconvinced that the current optional
> RTS support for mixed green/native threads is the right way
> to go. It looks to
> me like a workaround for poor OS support for really
> lightweight threads.
It is a workaround for the lack of truly lightweight threads at the OS
level. But I
| I propose adding something like
|
| forkNativeThread :: IO () -> IO ()
I haven't talked to Simon about this, but it sounds possible. Three
thoughts.
First, before doing anything like this I'd like to ask you or someone
else, or a group, to write a clear exposition of what the problem is and
I wrote:
> [...] Note that the fact that only one Haskell thread may execute at
a
> time remains unchanged. [...]
Sven Panne wrote:
I haven't thought very deeply about your proposal yet, but I don't
understand
the remark above: What about e.g. a multi-processor Solaris machine
(where
pthreads
On Sun, 17 Nov 2002 12:23:06 +0100 Sven Panne wrote:
>> Nevertheless, you make a good point: Better support for "real"
>> multi-threading is definitely an area where I'd like to see some
>> improvement for the next non-patchlevel release of GHC. I'm still
>> unconvinced that the current optional RT
On Sun, 17 Nov 2002 12:23:06 +0100
Sven Panne <[EMAIL PROTECTED]> wrote:
> Nevertheless, you make a good point: Better support for "real"
> multi-threading is definitely an area where I'd like to see some
> improvement for the next non-patchlevel release of GHC. I'm still
> unconvinced that the cur
Wolfgang Thaller wrote:
> [...] I propose adding something like
>
> forkNativeThread :: IO () -> IO ()
>
> which forks a new Haskell thread that has its own OS thread to execute
> in. Note that the fact that only one Haskell thread may execute at a
> time remains unchanged. [...]
I haven't thought
Hello All,
A while ago there was a discussion on the shortcomings of the threaded
RTS (in short, it doesn't work with foreign APIs that use thread-local
state, and that breaks HOpenGL). Back then, it was decided to just keep
the threaded RTS off by default and to do something about it some time
52 matches
Mail list logo
