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.
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 tricky
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
| 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?
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
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,c,d are
[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
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 threads
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 only
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
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
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
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 not
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
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]
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 and
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]
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
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?
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. Did you
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.
Perhaps
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 a fourth
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 forkIO?
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't
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
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
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
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
| 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'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
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 very
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 current
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 RTS support
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
34 matches
Mail list logo
