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 (
On Mittwoch, Juni 19, 2002, at 01:43 , Andrew J Bromage wrote:
> I don't mean to detract from the fine work which the HOpenGL people
> have achieved, but I think that binding to the C implementation of GLUT
> was, in retrospect, a mistake.
The problem here is with OpenGL, not with GLUT. OpenGL r
G'day all.
On Tue, Jun 18, 2002 at 05:58:15PM +0100, Alastair Reid wrote:
> A further piece of what one might call thread local state is
> 'recursive locks' like those found in Java.
Recursive locks arguably should be part of the lock abstraction, not
"thread local state ". Since all it costs
I have implemented a hack that makes HOpenGL work with
--enable-threaded-rts. It currently contains 3 lines of MacOS X-specific
code, and it needs cleaning up. More about that later.
> Simon and I don't understand GLUT's requirements at all clearly.
> Why is the context thread-local?
OpenGL
> Yes, these are all problems. However, there is a nice abstraction
> of the OS thread API in GHC's RTS, thanks to Sigbjorn. So I'm sure
> this API could be extended to include some thread-local state
> operations.
A further piece of what one might call thread local state is
'recursive locks'
t: 18 June 2002 15:06
| To: [EMAIL PROTECTED]
| Cc: GHC List
| Subject: Re: [HOpenGL] HOpenGL and --enable-threaded-rts
|
|
| Simon Marlow wrote:
| > [...] a given Haskell thread can even migrate from one OS thread to
| > another during its execution.
|
| Uh, oh! %-( Under which circum
Simon Marlow wrote:
> The trouble is that there isn't a single object representing the whole
> thread-local state. Does OpenGL use pthread_getspecific() and
> pthread_setspecific() to access its thread-local state?
The libGL supplied with XFree86 uses xthread_{get,set}_specific. These
are macr
Let me ask a naive question concerning the implementation of threading in
the GHC RTS. Would it be feasible to support an alternative strategy for
mapping Haskell threads onto OS threads, namely that the two sets are kept
in one-to-one correspondence? The thread multiplexing and migration that
G
Simon Marlow wrote:
> [...] a given Haskell thread can even migrate from one OS thread to
> another during its execution.
Uh, oh! %-( Under which circumstances exactly? I fear this will give
loads of fun with many C libraries out there, so it's important to know...
Cheers,
S.
__
> I'm slowly losing track of this discussion...
so am I :-(
> My initial suggestion
> was that it is guaranteed that the same OS thread which created the
> f.i.w. thunk is used to call back to Haskell for *this*
> wrapped function.
> There is no overhead for calls Haskell->C, only for the compa
I'm slowly losing track of this discussion... My initial suggestion
was that it is guaranteed that the same OS thread which created the
f.i.w. thunk is used to call back to Haskell for *this* wrapped function.
There is no overhead for calls Haskell->C, only for the comparatively
rare case of C->Ha
> This sounds like a lot of work and a porting nightmare (what do you
> mean Linux/Win32/HPUX/... doesn't have thread manipulation function X,
> it's available on FreeBSD/Win32/... What if there are other forms
> of thread-local state (e.g., errno)? What about setjmp/longjmp?).
Yes, these are
SimonM:
> Yes, my guess is that this will probably have to be done by
> manipulating the thread-local state in the RTS - grab the current
> thread-local state whenever a call is made into Haskell, and
> whenever we run a Haskell thread we have to set the appropriate
> thread-local state. Perhaps
> Has anyone already thought about how to solve this problem?
> I'm thinking about adding hooks to the RTS (in grabCapability,
> releaseCapability and scheduleThread_) which would be used
> for setting
> up the correct thread-local state whenever Haskell execution
> "switches"
> to a differe
In short, it doesn't work :-( .
OpenGL (at least on MacOS) keeps track of the "current context" on a
per-thread basis. The GLUT library sets the current context and calls
back to the program. With GHC 5.03 compiled with --enable-threaded-rts,
the callback gets executed in a different thread. Th
15 matches
Mail list logo
