Summary so far (was: HOpenGL and --enable-threaded-rts)

[Wolfgang Thaller]

--Apple-Mail-1--947920768
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Simon Marlow wrote:
> This discussion is getting rather long, so I thought I'd summarise (as
> much for my benefit as everyone else's).  Please let me know if I get
> anything wrong.

I haven't found anything wrong.

> I'm pretty sure (1) and (2) aren't viable, though.

I basically agree. In the presence (3) or (4) [or (5) ;-) ], my own hack 
looks like - well - a hack. I'll definitely use it as a short term 
solution for my own toy projects, though. I won't commit any code, but 
if anyone else needs a short-term solution for HOpenGL, they can ask me.

> Personally I can't decide whether (3) or (4) is the better solution.

I'd say, let's go for (5) - that is, some blend between (3) or (4). (4) 
almost sounds like (3) could be implemented on top of it. The simplicity 
of (3) is needed in most cases, the power of something like (4) in some.

Some other random thoughts:

Does the "OS-thread"-binding have to be a permanent attribute of a 
thread, or can we also have something like:

inOSThread theGLUTThread $ do
    ...

This could be useful for finalizers, or when some thread-sensitive API 
is used only "some of the time". The problem is that the haskell thread 
in question could be blocked indefinitely until the OS thread decides to 
return to Haskell code.
I do also like the idea of a forkHeavyIOThread primitive.
If something like (4) is implemented, it should still be possible to say 
that a Haskell thread can run in any OS thread. We never know what new 
ways of juggling threads (SMP, distributed systems?) will be supported 
in the future for code that "doesn't mind" being executed in different 
threads. The current limitations of the RTS (i.e. haskell code can only 
run in one OS thread at one time) should be a well-documented 
implementation detail, not a fundamental assumption for the threading 
primitives. The "don't care" thread group could still support features 
like the current threaded rts. The documentation will just have to make 
clear that it can't be predicted which OS thread those haskell threads 
will be run in, and that some libraries don't like that.

CU,

Wolfgang

--Apple-Mail-1--947920768
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Simon Marlow wrote:

<excerpt>This discussion is getting rather long, so I thought I'd
summarise (as

much for my benefit as everyone else's).  Please let me know if I get

anything wrong.

</excerpt>

I haven't found anything wrong.


<excerpt><color><param>0000,0000,DEDE</param>I'm pretty sure (1) and
(2) aren't viable, though.

</color></excerpt>

I basically agree. In the presence (3) or (4) [or (5) ;-) ], my own
hack looks like - well - a hack. I'll definitely use it as a short
term solution for my own toy projects, though. I won't commit any
code, but if anyone else needs a short-term solution for HOpenGL, they
can ask me.


<excerpt><color><param>0000,0000,DEDE</param>Personally I can't decide
whether (3) or (4) is the better solution.

</color></excerpt>

I'd say, let's go for (5) - that is, some blend between (3) or (4).
(4) almost sounds like (3) could be implemented on top of it. The
simplicity of (3) is needed in most cases, the power of something like
(4) in some.


Some other random thoughts:


Does the "OS-thread"-binding have to be a permanent attribute of a
thread, or can we also have something like:


inOSThread theGLUTThread $ do

   ...


This could be useful for finalizers, or when some thread-sensitive API
is used only "some of the time". The problem is that the haskell
thread in question could be blocked indefinitely until the OS thread
decides to return to Haskell code.

I do also like the idea of a forkHeavyIOThread primitive. 

If something like (4) is implemented, it should still be possible to
say that a Haskell thread can run in any OS thread. We never know what
new ways of juggling threads (SMP, distributed systems?) will be
supported in the future for code that "doesn't mind" being executed in
different threads. The current limitations of the RTS (i.e. haskell
code can only run in one OS thread at one time) should be a
well-documented implementation detail, not a fundamental assumption
for the threading primitives. The "don't care" thread group could
still support features like the current threaded rts. The
documentation will just have to make clear that it can't be predicted
which OS thread those haskell threads will be run in, and that some
libraries don't like that.


CU,


Wolfgang
--Apple-Mail-1--947920768--