Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[David Barbour]

On Tue, Jul 12, 2011 at 2:58 AM, Simon Marlow  wrote:

> I discovered the real reason we run statements in a separate thread: the
> GHCi debugger.  If the computation stops at a breakpoint, then we have to
> save the context and resume GHCi, which can only be done if the computation
> was running in a separate thread.
>
> The way things are arranged right now, each stopped computation gets a
> different thread.  What you want is for all these to be on the main thread.
>  It might be possible to arrange this, but it would require some non-trivial
> reorganisation in the implementation of interactive evaluation
> (compiler/main/**InteractiveEval.hs).  I'm going to have to leave this for
> now, sorry.  In the meantime you'll still be able to use -fno-ghci-sandbox,
> but the debugging features in GHCi will be disabled.
>
> Cheers,
>Simon
>
>
Thanks for looking into it, Simon.

Regards,

Dave
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 07/07/2011 08:41, Simon Marlow wrote:

On 06/07/2011 21:19, Jason Dagit wrote:

On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow wrote:

On 06/07/11 17:14, David Barbour wrote:



On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlowmailto:marlo...@gmail.com>> wrote:

On 06/07/2011 15:42, Jason Dagit wrote:

How can I make sure my library works from GHC (with arbitrary

user threads) and from GHCI?

Right, but usually the way this is implemented is with some
cooperation from the main thread. [...] So you can't just do this
from a library - the main thread has to be in on the game. I suppose
you might wonder whether the GHC RTS could implement runInMainThread
by preempting the main thread and running some different code on it.
[...]


I think the real issue is that GHC has a different behavior than GHCi,
and I think this causes a lot of difficulties for people working on GUI
and other FFI integration.

Perhaps it would be possible to reverse the default roles of threads in
GHCi: the main thread run user commands, and a second bound thread will
process user interrupts and such.


Well, GHCi has no main, so it doesn't seem surprising (to me) that it's
different.

However, if -fno-ghci-sandbox doesn't have any drawbacks we could
just make
it the default. I don't actually remember why we run each statement in a
new thread, I think it just seemed like a prudent thing to do.


+1 for this change. I'm not sure how we would know if there are
drawbacks.


Now that I think about it, the original reason may have been that if the
computation grows a large stack, having it in a separate thread means
GHCi can recover the memory. However we have been able to recover stack
memory for some time now, so that is no longer an issue.


I discovered the real reason we run statements in a separate thread: the 
GHCi debugger.  If the computation stops at a breakpoint, then we have 
to save the context and resume GHCi, which can only be done if the 
computation was running in a separate thread.


The way things are arranged right now, each stopped computation gets a 
different thread.  What you want is for all these to be on the main 
thread.  It might be possible to arrange this, but it would require some 
non-trivial reorganisation in the implementation of interactive 
evaluation (compiler/main/InteractiveEval.hs).  I'm going to have to 
leave this for now, sorry.  In the meantime you'll still be able to use 
-fno-ghci-sandbox, but the debugging features in GHCi will be disabled.


Cheers,
Simon




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Thu, Jul 7, 2011 at 12:41 AM, Simon Marlow  wrote:
> On 06/07/2011 21:19, Jason Dagit wrote:
>>
>> On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow  wrote:
>>>
>>> On 06/07/11 17:14, David Barbour wrote:


 On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow>>> >  wrote:

    On 06/07/2011 15:42, Jason Dagit wrote:

        How can I make sure my library works from GHC (with arbitrary

        user threads) and from GHCI?

    Right, but usually the way this is implemented is with some
    cooperation from the main thread. [...] So you can't just do this
    from a library - the main thread has to be in on the game. I suppose
    you might wonder whether the GHC RTS could implement runInMainThread
    by preempting the main thread and running some different code on it.
      [...]


 I think the real issue is that GHC has a different behavior than GHCi,
 and I think this causes a lot of difficulties for people working on GUI
 and other FFI integration.

 Perhaps it would be possible to reverse the default roles of threads in
 GHCi: the main thread run user commands, and a second bound thread will
 process user interrupts and such.
>>>
>>> Well, GHCi has no main, so it doesn't seem surprising (to me) that it's
>>> different.
>>>
>>> However, if -fno-ghci-sandbox doesn't have any drawbacks we could just
>>> make
>>> it the default.  I don't actually remember why we run each statement in a
>>> new thread, I think it just seemed like a prudent thing to do.
>>
>> +1 for this change.  I'm not sure how we would know if there are
>> drawbacks.
>
> Now that I think about it, the original reason may have been that if the
> computation grows a large stack, having it in a separate thread means GHCi
> can recover the memory.  However we have been able to recover stack memory
> for some time now, so that is no longer an issue.

Then by all means, please make -fno-ghci-sandbox the default! :)

Thanks
Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/2011 21:19, Jason Dagit wrote:

On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow  wrote:

On 06/07/11 17:14, David Barbour wrote:



On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlowmailto:marlo...@gmail.com>>  wrote:

On 06/07/2011 15:42, Jason Dagit wrote:

How can I make sure my library works from GHC (with arbitrary

user threads) and from GHCI?

Right, but usually the way this is implemented is with some
cooperation from the main thread. [...] So you can't just do this
from a library - the main thread has to be in on the game. I suppose
you might wonder whether the GHC RTS could implement runInMainThread
by preempting the main thread and running some different code on it.
  [...]


I think the real issue is that GHC has a different behavior than GHCi,
and I think this causes a lot of difficulties for people working on GUI
and other FFI integration.

Perhaps it would be possible to reverse the default roles of threads in
GHCi: the main thread run user commands, and a second bound thread will
process user interrupts and such.


Well, GHCi has no main, so it doesn't seem surprising (to me) that it's
different.

However, if -fno-ghci-sandbox doesn't have any drawbacks we could just make
it the default.  I don't actually remember why we run each statement in a
new thread, I think it just seemed like a prudent thing to do.


+1 for this change.  I'm not sure how we would know if there are drawbacks.


Now that I think about it, the original reason may have been that if the 
computation grows a large stack, having it in a separate thread means 
GHCi can recover the memory.  However we have been able to recover stack 
memory for some time now, so that is no longer an issue.


Cheers,
Simon

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/2011 21:11, David Barbour wrote:

On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:

I think the real issue is that GHC has a different behavior than
GHCi,
and I think this causes a lot of difficulties for people working
on GUI
and other FFI integration.

Well, GHCi has no main, so it doesn't seem surprising (to me) that
it's different.


If we start GHCi then run the function called 'main', we should ideally
get the same behavior as building with GHC then executing the process.
Variations make exploratory programming with GHCi very difficult,
especially with concurrent haskell.


That's a fair point.


However, if -fno-ghci-sandbox doesn't have any drawbacks we could
just make it the default.


That sounds good, too. I think it worth looking up what the drawbacks
will be. It might be an acceptable trade even if there are minor
drawbacks. I would imagine the main benefit of the sandbox is ability to
interrupt a task - i.e. job control from the GHCi shell.


Interruption is not affected, as far as I'm aware.

Cheers,
Simon

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow  wrote:
> On 06/07/11 17:14, David Barbour wrote:
>>
>>
>> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow > > wrote:
>>
>>    On 06/07/2011 15:42, Jason Dagit wrote:
>>
>>        How can I make sure my library works from GHC (with arbitrary
>>
>>        user threads) and from GHCI?
>>
>>    Right, but usually the way this is implemented is with some
>>    cooperation from the main thread. [...] So you can't just do this
>>    from a library - the main thread has to be in on the game. I suppose
>>    you might wonder whether the GHC RTS could implement runInMainThread
>>    by preempting the main thread and running some different code on it.
>>      [...]
>>
>>
>> I think the real issue is that GHC has a different behavior than GHCi,
>> and I think this causes a lot of difficulties for people working on GUI
>> and other FFI integration.
>>
>> Perhaps it would be possible to reverse the default roles of threads in
>> GHCi: the main thread run user commands, and a second bound thread will
>> process user interrupts and such.
>
> Well, GHCi has no main, so it doesn't seem surprising (to me) that it's
> different.
>
> However, if -fno-ghci-sandbox doesn't have any drawbacks we could just make
> it the default.  I don't actually remember why we run each statement in a
> new thread, I think it just seemed like a prudent thing to do.

+1 for this change.  I'm not sure how we would know if there are drawbacks.

Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[David Barbour]

On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow  wrote:
>
> I think the real issue is that GHC has a different behavior than GHCi,
>> and I think this causes a lot of difficulties for people working on GUI
>> and other FFI integration.
>>
>

Well, GHCi has no main, so it doesn't seem surprising (to me) that it's
> different.
>

If we start GHCi then run the function called 'main', we should ideally get
the same behavior as building with GHC then executing the process.
Variations make exploratory programming with GHCi very difficult, especially
with concurrent haskell.


> However, if -fno-ghci-sandbox doesn't have any drawbacks we could just make
> it the default.


That sounds good, too. I think it worth looking up what the drawbacks will
be. It might be an acceptable trade even if there are minor drawbacks. I
would imagine the main benefit of the sandbox is ability to interrupt a task
- i.e. job control from the GHCi shell.

Regards,

Dave
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/11 17:19, Gábor Lehel wrote:

On Wed, Jul 6, 2011 at 5:24 PM, Jason Dagit  wrote:

On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:

On 06/07/2011 15:42, Jason Dagit wrote:


On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlowwrote:


On 06/07/2011 07:37, Jason Dagit wrote:


On Jul 5, 2011 1:04 PM, "Jason Dagit"mailto:dag...@gmail.com>>wrote:
  >
  >On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynaghmailto:ig...@earth.li>>wrote:
  >>On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
  >>>
  >>>In GHCi it's a different matter, because the main thread is
running
  >>>GHCi itself, and all the expressions/statements typed at the
prompt
  >>>are run in forkIO'd threads (a new one for each statement, in
fact).
  >>>If you want a way to run command-line operations in the main
thread,
  >>>please submit a feature request.  I'm not sure it can be done,
but
  >>>I'll look into it.
  >>
  >>We already have a way: -fno-ghci-sandbox
  >
  >I've removed all my explicit attempts to forkIO/forkOS and passed
the
  >command line flag you mention.  I just tried this but it doesn't
  >change the behavior in my example.

I tried it again and discovered that due to an argument parsing bug in
cabal-dev that the flag was not passed correctly. I explicitly passed it
and verified that it works. Thanks for the workaround. By the way, I did
look at the user guide for options like this and didn't see it. Which
part of the manual is it in?

Can I still make a feature request for a function to make code run on
the original thread? My reasoning is that the code which needs to run on
the main thread may appear in a library in which case the developer has
no control over how ghc is invoked.


I'm not sure how that would work.  The programmer is in control of what
the
main thread does, not GHC.  So in order to implement some mechanism to
run
code on the main thread, we would need some cooperation from the main
thread
itself.  For example, in gtk2hs the main thread runs an event handler
loop
which occasionally checks a queue for requests from other threads (at
least,
I think that's how it works).


What I'm wrestling with is the following.  Say I make a GUI library.
As author of the GUI library I discover issues like this where the
library code needs to execute on the "main" thread.  Users of the
library expect the typical Haskell environment where you can't tell
the difference between threads, and you fork at will.  How can I make
sure my library works from GHC (with arbitrary user threads) and from
GHCI?

As John Lato points out in his email lots of people bump into this
without realizing it and don't understand what the problem is.  We can
try our best to educate everyone, but I have this sense that we could
also do a better job of providing primitives to make it so that code
will run on the main thread regardless of how people invoke the
library.

In my specific case (Cocoa on OSX), it is possible for me to use some
Cocoa functions to force things to run on the main thread.  From what
I've read Cocoa uses pthreads to implement this. I was hoping we could
expose something from the RTS code in Control.Concurrent so that it's
part of an "official" Haskell API that library writers can assume.

Judging by this SO question, it's easier to implement this in Haskell
on top of pthreads than to implement it in C (here I'm assuming GHC's
RTS uses pthreads, but I've never checked):

http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

In fact, the it sounds like what Gtk2hs is doing with the postGUI
functions.


Right, but usually the way this is implemented is with some cooperation from
the main thread.  That SO answer explains it - the main thread runs some
kind of loop that periodically checks for requests from other threads and
services them.  I expect that's how it works on Cocoa.
So you can't just do this from a library - the main thread has to be in on
the game.


Yes.  From my perspective (that of a library writer) that's what makes
this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
perspective it's tricky too.


I suppose you might wonder whether the GHC RTS could implement
runInMainThread by preempting the main thread and running some different
code on it.


Yes, that's roughly what I was wondering about.



There's more than one reason why a (GUI) library might require
functions to be called only from the main thread. One is if the
library uses thread-local storage, in which case the code needs to run
in the right thread to see the right data. I've heard that OpenGL is
like this. Another (more common, as far as I know) reason is if (parts
of) the library aren't thread safe, and can't handle more than one
thread at a time simultaneously calling its functions and mutating its
members. I'm not sure if there are other reasons.


Yes, this we know (see the Concurrency/FFI paper I linked earli

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/11 17:14, David Barbour wrote:



On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow mailto:marlo...@gmail.com>> wrote:

On 06/07/2011 15:42, Jason Dagit wrote:

How can I make sure my library works from GHC (with arbitrary

user threads) and from GHCI?

Right, but usually the way this is implemented is with some
cooperation from the main thread. [...] So you can't just do this
from a library - the main thread has to be in on the game. I suppose
you might wonder whether the GHC RTS could implement runInMainThread
by preempting the main thread and running some different code on it.
  [...]


I think the real issue is that GHC has a different behavior than GHCi,
and I think this causes a lot of difficulties for people working on GUI
and other FFI integration.

Perhaps it would be possible to reverse the default roles of threads in
GHCi: the main thread run user commands, and a second bound thread will
process user interrupts and such.


Well, GHCi has no main, so it doesn't seem surprising (to me) that it's 
different.


However, if -fno-ghci-sandbox doesn't have any drawbacks we could just 
make it the default.  I don't actually remember why we run each 
statement in a new thread, I think it just seemed like a prudent thing 
to do.


Cheers,
Simon

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Gábor Lehel]

2011/7/6 Gábor Lehel :
> 2011/7/6 Gábor Lehel :
>> On Wed, Jul 6, 2011 at 5:24 PM, Jason Dagit  wrote:
>>> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:
 On 06/07/2011 15:42, Jason Dagit wrote:
>
> On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:
>>
>> On 06/07/2011 07:37, Jason Dagit wrote:
>>>
>>> On Jul 5, 2011 1:04 PM, "Jason Dagit">> >  wrote:
>>>  >
>>>  >  On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh>> >  wrote:
>>>  >  >  On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
>>>  >  >>
>>>  >  >>  In GHCi it's a different matter, because the main thread is
>>> running
>>>  >  >>  GHCi itself, and all the expressions/statements typed at the
>>> prompt
>>>  >  >>  are run in forkIO'd threads (a new one for each statement, in
>>> fact).
>>>  >  >>  If you want a way to run command-line operations in the main
>>> thread,
>>>  >  >>  please submit a feature request.  I'm not sure it can be done,
>>> but
>>>  >  >>  I'll look into it.
>>>  >  >
>>>  >  >  We already have a way: -fno-ghci-sandbox
>>>  >
>>>  >  I've removed all my explicit attempts to forkIO/forkOS and passed
>>> the
>>>  >  command line flag you mention.  I just tried this but it doesn't
>>>  >  change the behavior in my example.
>>>
>>> I tried it again and discovered that due to an argument parsing bug in
>>> cabal-dev that the flag was not passed correctly. I explicitly passed it
>>> and verified that it works. Thanks for the workaround. By the way, I did
>>> look at the user guide for options like this and didn't see it. Which
>>> part of the manual is it in?
>>>
>>> Can I still make a feature request for a function to make code run on
>>> the original thread? My reasoning is that the code which needs to run on
>>> the main thread may appear in a library in which case the developer has
>>> no control over how ghc is invoked.
>>
>> I'm not sure how that would work.  The programmer is in control of what
>> the
>> main thread does, not GHC.  So in order to implement some mechanism to
>> run
>> code on the main thread, we would need some cooperation from the main
>> thread
>> itself.  For example, in gtk2hs the main thread runs an event handler
>> loop
>> which occasionally checks a queue for requests from other threads (at
>> least,
>> I think that's how it works).
>
> What I'm wrestling with is the following.  Say I make a GUI library.
> As author of the GUI library I discover issues like this where the
> library code needs to execute on the "main" thread.  Users of the
> library expect the typical Haskell environment where you can't tell
> the difference between threads, and you fork at will.  How can I make
> sure my library works from GHC (with arbitrary user threads) and from
> GHCI?
>
> As John Lato points out in his email lots of people bump into this
> without realizing it and don't understand what the problem is.  We can
> try our best to educate everyone, but I have this sense that we could
> also do a better job of providing primitives to make it so that code
> will run on the main thread regardless of how people invoke the
> library.
>
> In my specific case (Cocoa on OSX), it is possible for me to use some
> Cocoa functions to force things to run on the main thread.  From what
> I've read Cocoa uses pthreads to implement this. I was hoping we could
> expose something from the RTS code in Control.Concurrent so that it's
> part of an "official" Haskell API that library writers can assume.
>
> Judging by this SO question, it's easier to implement this in Haskell
> on top of pthreads than to implement it in C (here I'm assuming GHC's
> RTS uses pthreads, but I've never checked):
>
> http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread
>
> In fact, the it sounds like what Gtk2hs is doing with the postGUI
> functions.

 Right, but usually the way this is implemented is with some cooperation 
 from
 the main thread.  That SO answer explains it - the main thread runs some
 kind of loop that periodically checks for requests from other threads and
 services them.  I expect that's how it works on Cocoa.
 So you can't just do this from a library - the main thread has to be in on
 the game.
>>>
>>> Yes.  From my perspective (that of a library writer) that's what makes
>>> this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
>>> perspective it's tricky too.
>>>
 I suppose you might wonder whether the GHC RTS could implement
 runInMainThread by preempting the main thread and running some different
 code on it.
>>>
>>> Yes, that's roughly what I was wondering abou

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Gábor Lehel]

2011/7/6 Gábor Lehel :
> On Wed, Jul 6, 2011 at 5:24 PM, Jason Dagit  wrote:
>> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:
>>> On 06/07/2011 15:42, Jason Dagit wrote:

 On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:
>
> On 06/07/2011 07:37, Jason Dagit wrote:
>>
>> On Jul 5, 2011 1:04 PM, "Jason Dagit"> >  wrote:
>>  >
>>  >  On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh> >  wrote:
>>  >  >  On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
>>  >  >>
>>  >  >>  In GHCi it's a different matter, because the main thread is
>> running
>>  >  >>  GHCi itself, and all the expressions/statements typed at the
>> prompt
>>  >  >>  are run in forkIO'd threads (a new one for each statement, in
>> fact).
>>  >  >>  If you want a way to run command-line operations in the main
>> thread,
>>  >  >>  please submit a feature request.  I'm not sure it can be done,
>> but
>>  >  >>  I'll look into it.
>>  >  >
>>  >  >  We already have a way: -fno-ghci-sandbox
>>  >
>>  >  I've removed all my explicit attempts to forkIO/forkOS and passed
>> the
>>  >  command line flag you mention.  I just tried this but it doesn't
>>  >  change the behavior in my example.
>>
>> I tried it again and discovered that due to an argument parsing bug in
>> cabal-dev that the flag was not passed correctly. I explicitly passed it
>> and verified that it works. Thanks for the workaround. By the way, I did
>> look at the user guide for options like this and didn't see it. Which
>> part of the manual is it in?
>>
>> Can I still make a feature request for a function to make code run on
>> the original thread? My reasoning is that the code which needs to run on
>> the main thread may appear in a library in which case the developer has
>> no control over how ghc is invoked.
>
> I'm not sure how that would work.  The programmer is in control of what
> the
> main thread does, not GHC.  So in order to implement some mechanism to
> run
> code on the main thread, we would need some cooperation from the main
> thread
> itself.  For example, in gtk2hs the main thread runs an event handler
> loop
> which occasionally checks a queue for requests from other threads (at
> least,
> I think that's how it works).

 What I'm wrestling with is the following.  Say I make a GUI library.
 As author of the GUI library I discover issues like this where the
 library code needs to execute on the "main" thread.  Users of the
 library expect the typical Haskell environment where you can't tell
 the difference between threads, and you fork at will.  How can I make
 sure my library works from GHC (with arbitrary user threads) and from
 GHCI?

 As John Lato points out in his email lots of people bump into this
 without realizing it and don't understand what the problem is.  We can
 try our best to educate everyone, but I have this sense that we could
 also do a better job of providing primitives to make it so that code
 will run on the main thread regardless of how people invoke the
 library.

 In my specific case (Cocoa on OSX), it is possible for me to use some
 Cocoa functions to force things to run on the main thread.  From what
 I've read Cocoa uses pthreads to implement this. I was hoping we could
 expose something from the RTS code in Control.Concurrent so that it's
 part of an "official" Haskell API that library writers can assume.

 Judging by this SO question, it's easier to implement this in Haskell
 on top of pthreads than to implement it in C (here I'm assuming GHC's
 RTS uses pthreads, but I've never checked):

 http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

 In fact, the it sounds like what Gtk2hs is doing with the postGUI
 functions.
>>>
>>> Right, but usually the way this is implemented is with some cooperation from
>>> the main thread.  That SO answer explains it - the main thread runs some
>>> kind of loop that periodically checks for requests from other threads and
>>> services them.  I expect that's how it works on Cocoa.
>>> So you can't just do this from a library - the main thread has to be in on
>>> the game.
>>
>> Yes.  From my perspective (that of a library writer) that's what makes
>> this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
>> perspective it's tricky too.
>>
>>> I suppose you might wonder whether the GHC RTS could implement
>>> runInMainThread by preempting the main thread and running some different
>>> code on it.
>>
>> Yes, that's roughly what I was wondering about.
>
>
> There's more than one reason why a (GUI) library might require
> functions to be called only from the main thread. One is if 

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[David Barbour]

On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:

> On 06/07/2011 15:42, Jason Dagit wrote:
>
>> How can I make sure my library works from GHC (with arbitrary
>
> user threads) and from GHCI?
>>
>

Right, but usually the way this is implemented is with some cooperation from
> the main thread. [...] So you can't just do this from a library - the main
> thread has to be in on the game. I suppose you might wonder whether the GHC
> RTS could implement runInMainThread by preempting the main thread and
> running some different code on it.  [...]
>

I think the real issue is that GHC has a different behavior than GHCi, and I
think this causes a lot of difficulties for people working on GUI and other
FFI integration.

Perhaps it would be possible to reverse the default roles of threads in
GHCi: the main thread run user commands, and a second bound thread will
process user interrupts and such.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Gábor Lehel]

On Wed, Jul 6, 2011 at 5:24 PM, Jason Dagit  wrote:
> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:
>> On 06/07/2011 15:42, Jason Dagit wrote:
>>>
>>> On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:

 On 06/07/2011 07:37, Jason Dagit wrote:
>
> On Jul 5, 2011 1:04 PM, "Jason Dagit" >  wrote:
>  >
>  >  On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh >  wrote:
>  >  >  On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
>  >  >>
>  >  >>  In GHCi it's a different matter, because the main thread is
> running
>  >  >>  GHCi itself, and all the expressions/statements typed at the
> prompt
>  >  >>  are run in forkIO'd threads (a new one for each statement, in
> fact).
>  >  >>  If you want a way to run command-line operations in the main
> thread,
>  >  >>  please submit a feature request.  I'm not sure it can be done,
> but
>  >  >>  I'll look into it.
>  >  >
>  >  >  We already have a way: -fno-ghci-sandbox
>  >
>  >  I've removed all my explicit attempts to forkIO/forkOS and passed
> the
>  >  command line flag you mention.  I just tried this but it doesn't
>  >  change the behavior in my example.
>
> I tried it again and discovered that due to an argument parsing bug in
> cabal-dev that the flag was not passed correctly. I explicitly passed it
> and verified that it works. Thanks for the workaround. By the way, I did
> look at the user guide for options like this and didn't see it. Which
> part of the manual is it in?
>
> Can I still make a feature request for a function to make code run on
> the original thread? My reasoning is that the code which needs to run on
> the main thread may appear in a library in which case the developer has
> no control over how ghc is invoked.

 I'm not sure how that would work.  The programmer is in control of what
 the
 main thread does, not GHC.  So in order to implement some mechanism to
 run
 code on the main thread, we would need some cooperation from the main
 thread
 itself.  For example, in gtk2hs the main thread runs an event handler
 loop
 which occasionally checks a queue for requests from other threads (at
 least,
 I think that's how it works).
>>>
>>> What I'm wrestling with is the following.  Say I make a GUI library.
>>> As author of the GUI library I discover issues like this where the
>>> library code needs to execute on the "main" thread.  Users of the
>>> library expect the typical Haskell environment where you can't tell
>>> the difference between threads, and you fork at will.  How can I make
>>> sure my library works from GHC (with arbitrary user threads) and from
>>> GHCI?
>>>
>>> As John Lato points out in his email lots of people bump into this
>>> without realizing it and don't understand what the problem is.  We can
>>> try our best to educate everyone, but I have this sense that we could
>>> also do a better job of providing primitives to make it so that code
>>> will run on the main thread regardless of how people invoke the
>>> library.
>>>
>>> In my specific case (Cocoa on OSX), it is possible for me to use some
>>> Cocoa functions to force things to run on the main thread.  From what
>>> I've read Cocoa uses pthreads to implement this. I was hoping we could
>>> expose something from the RTS code in Control.Concurrent so that it's
>>> part of an "official" Haskell API that library writers can assume.
>>>
>>> Judging by this SO question, it's easier to implement this in Haskell
>>> on top of pthreads than to implement it in C (here I'm assuming GHC's
>>> RTS uses pthreads, but I've never checked):
>>>
>>> http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread
>>>
>>> In fact, the it sounds like what Gtk2hs is doing with the postGUI
>>> functions.
>>
>> Right, but usually the way this is implemented is with some cooperation from
>> the main thread.  That SO answer explains it - the main thread runs some
>> kind of loop that periodically checks for requests from other threads and
>> services them.  I expect that's how it works on Cocoa.
>> So you can't just do this from a library - the main thread has to be in on
>> the game.
>
> Yes.  From my perspective (that of a library writer) that's what makes
> this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
> perspective it's tricky too.
>
>> I suppose you might wonder whether the GHC RTS could implement
>> runInMainThread by preempting the main thread and running some different
>> code on it.
>
> Yes, that's roughly what I was wondering about.


There's more than one reason why a (GUI) library might require
functions to be called only from the main thread. One is if the
library uses thread-local storage, in which case the code needs to run
in the right thread to see the right data. I've heard that

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Wed, Jul 6, 2011 at 8:51 AM, Simon Marlow  wrote:
> On 06/07/2011 16:24, Jason Dagit wrote:
>>
>> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:
>>>
>>> On 06/07/2011 15:42, Jason Dagit wrote:

 On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow
  wrote:
>
> On 06/07/2011 07:37, Jason Dagit wrote:
>>
>> On Jul 5, 2011 1:04 PM, "Jason Dagit"> >    wrote:
>>  >
>>  >    On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh> >    wrote:
>>  >    >    On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow
>> wrote:
>>  >    >>
>>  >    >>    In GHCi it's a different matter, because the main thread
>> is
>> running
>>  >    >>    GHCi itself, and all the expressions/statements typed at
>> the
>> prompt
>>  >    >>    are run in forkIO'd threads (a new one for each statement,
>> in
>> fact).
>>  >    >>    If you want a way to run command-line operations in the
>> main
>> thread,
>>  >    >>    please submit a feature request.  I'm not sure it can be
>> done,
>> but
>>  >    >>    I'll look into it.
>>  >    >
>>  >    >    We already have a way: -fno-ghci-sandbox
>>  >
>>  >    I've removed all my explicit attempts to forkIO/forkOS and
>> passed
>> the
>>  >    command line flag you mention.  I just tried this but it doesn't
>>  >    change the behavior in my example.
>>
>> I tried it again and discovered that due to an argument parsing bug in
>> cabal-dev that the flag was not passed correctly. I explicitly passed
>> it
>> and verified that it works. Thanks for the workaround. By the way, I
>> did
>> look at the user guide for options like this and didn't see it. Which
>> part of the manual is it in?
>>
>> Can I still make a feature request for a function to make code run on
>> the original thread? My reasoning is that the code which needs to run
>> on
>> the main thread may appear in a library in which case the developer
>> has
>> no control over how ghc is invoked.
>
> I'm not sure how that would work.  The programmer is in control of what
> the
> main thread does, not GHC.  So in order to implement some mechanism to
> run
> code on the main thread, we would need some cooperation from the main
> thread
> itself.  For example, in gtk2hs the main thread runs an event handler
> loop
> which occasionally checks a queue for requests from other threads (at
> least,
> I think that's how it works).

 What I'm wrestling with is the following.  Say I make a GUI library.
 As author of the GUI library I discover issues like this where the
 library code needs to execute on the "main" thread.  Users of the
 library expect the typical Haskell environment where you can't tell
 the difference between threads, and you fork at will.  How can I make
 sure my library works from GHC (with arbitrary user threads) and from
 GHCI?

 As John Lato points out in his email lots of people bump into this
 without realizing it and don't understand what the problem is.  We can
 try our best to educate everyone, but I have this sense that we could
 also do a better job of providing primitives to make it so that code
 will run on the main thread regardless of how people invoke the
 library.

 In my specific case (Cocoa on OSX), it is possible for me to use some
 Cocoa functions to force things to run on the main thread.  From what
 I've read Cocoa uses pthreads to implement this. I was hoping we could
 expose something from the RTS code in Control.Concurrent so that it's
 part of an "official" Haskell API that library writers can assume.

 Judging by this SO question, it's easier to implement this in Haskell
 on top of pthreads than to implement it in C (here I'm assuming GHC's
 RTS uses pthreads, but I've never checked):


 http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

 In fact, the it sounds like what Gtk2hs is doing with the postGUI
 functions.
>>>
>>> Right, but usually the way this is implemented is with some cooperation
>>> from
>>> the main thread.  That SO answer explains it - the main thread runs some
>>> kind of loop that periodically checks for requests from other threads and
>>> services them.  I expect that's how it works on Cocoa.
>>> So you can't just do this from a library - the main thread has to be in
>>> on
>>> the game.
>>
>> Yes.  From my perspective (that of a library writer) that's what makes
>> this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
>> perspective it's tricky too.
>>
>>> I suppose you might wonder whether the GHC RTS could implement
>>> runInMainThread by preempting the main thread and running some different
>>> code on it.
>>
>> Yes, that's

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/2011 16:24, Jason Dagit wrote:

On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:

On 06/07/2011 15:42, Jason Dagit wrote:


On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlowwrote:


On 06/07/2011 07:37, Jason Dagit wrote:


On Jul 5, 2011 1:04 PM, "Jason Dagit"mailto:dag...@gmail.com>>wrote:
  >
  >On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynaghmailto:ig...@earth.li>>wrote:
  >>On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
  >>>
  >>>In GHCi it's a different matter, because the main thread is
running
  >>>GHCi itself, and all the expressions/statements typed at the
prompt
  >>>are run in forkIO'd threads (a new one for each statement, in
fact).
  >>>If you want a way to run command-line operations in the main
thread,
  >>>please submit a feature request.  I'm not sure it can be done,
but
  >>>I'll look into it.
  >>
  >>We already have a way: -fno-ghci-sandbox
  >
  >I've removed all my explicit attempts to forkIO/forkOS and passed
the
  >command line flag you mention.  I just tried this but it doesn't
  >change the behavior in my example.

I tried it again and discovered that due to an argument parsing bug in
cabal-dev that the flag was not passed correctly. I explicitly passed it
and verified that it works. Thanks for the workaround. By the way, I did
look at the user guide for options like this and didn't see it. Which
part of the manual is it in?

Can I still make a feature request for a function to make code run on
the original thread? My reasoning is that the code which needs to run on
the main thread may appear in a library in which case the developer has
no control over how ghc is invoked.


I'm not sure how that would work.  The programmer is in control of what
the
main thread does, not GHC.  So in order to implement some mechanism to
run
code on the main thread, we would need some cooperation from the main
thread
itself.  For example, in gtk2hs the main thread runs an event handler
loop
which occasionally checks a queue for requests from other threads (at
least,
I think that's how it works).


What I'm wrestling with is the following.  Say I make a GUI library.
As author of the GUI library I discover issues like this where the
library code needs to execute on the "main" thread.  Users of the
library expect the typical Haskell environment where you can't tell
the difference between threads, and you fork at will.  How can I make
sure my library works from GHC (with arbitrary user threads) and from
GHCI?

As John Lato points out in his email lots of people bump into this
without realizing it and don't understand what the problem is.  We can
try our best to educate everyone, but I have this sense that we could
also do a better job of providing primitives to make it so that code
will run on the main thread regardless of how people invoke the
library.

In my specific case (Cocoa on OSX), it is possible for me to use some
Cocoa functions to force things to run on the main thread.  From what
I've read Cocoa uses pthreads to implement this. I was hoping we could
expose something from the RTS code in Control.Concurrent so that it's
part of an "official" Haskell API that library writers can assume.

Judging by this SO question, it's easier to implement this in Haskell
on top of pthreads than to implement it in C (here I'm assuming GHC's
RTS uses pthreads, but I've never checked):

http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

In fact, the it sounds like what Gtk2hs is doing with the postGUI
functions.


Right, but usually the way this is implemented is with some cooperation from
the main thread.  That SO answer explains it - the main thread runs some
kind of loop that periodically checks for requests from other threads and
services them.  I expect that's how it works on Cocoa.
So you can't just do this from a library - the main thread has to be in on
the game.


Yes.  From my perspective (that of a library writer) that's what makes
this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
perspective it's tricky too.


I suppose you might wonder whether the GHC RTS could implement
runInMainThread by preempting the main thread and running some different
code on it.


Yes, that's roughly what I was wondering about.


  In theory that's possible, but whether it's a good idea or not
is a different matter!  I think it amounts to the same thing as the gtk2hs
folks have been asking for - multiple Haskell threads bound to the same OS
thread.


I'm starting to realize that I don't understand the GHC threading
model very well :)  I thought that was already possible.  I may be
mixing GHC's thread model up with other language implementations, but
I thought that it had a pool of OS threads and that Haskell threads
ran on them as needed.  I think what you're saying is that the RTS has
bound threads and it has thread pooling, but what it doesn't have is
"bound 

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:
> On 06/07/2011 15:42, Jason Dagit wrote:
>>
>> On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:
>>>
>>> On 06/07/2011 07:37, Jason Dagit wrote:

 On Jul 5, 2011 1:04 PM, "Jason Dagit">>> >  wrote:
  >
  >  On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh>>> >  wrote:
  >  >  On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
  >  >>
  >  >>  In GHCi it's a different matter, because the main thread is
 running
  >  >>  GHCi itself, and all the expressions/statements typed at the
 prompt
  >  >>  are run in forkIO'd threads (a new one for each statement, in
 fact).
  >  >>  If you want a way to run command-line operations in the main
 thread,
  >  >>  please submit a feature request.  I'm not sure it can be done,
 but
  >  >>  I'll look into it.
  >  >
  >  >  We already have a way: -fno-ghci-sandbox
  >
  >  I've removed all my explicit attempts to forkIO/forkOS and passed
 the
  >  command line flag you mention.  I just tried this but it doesn't
  >  change the behavior in my example.

 I tried it again and discovered that due to an argument parsing bug in
 cabal-dev that the flag was not passed correctly. I explicitly passed it
 and verified that it works. Thanks for the workaround. By the way, I did
 look at the user guide for options like this and didn't see it. Which
 part of the manual is it in?

 Can I still make a feature request for a function to make code run on
 the original thread? My reasoning is that the code which needs to run on
 the main thread may appear in a library in which case the developer has
 no control over how ghc is invoked.
>>>
>>> I'm not sure how that would work.  The programmer is in control of what
>>> the
>>> main thread does, not GHC.  So in order to implement some mechanism to
>>> run
>>> code on the main thread, we would need some cooperation from the main
>>> thread
>>> itself.  For example, in gtk2hs the main thread runs an event handler
>>> loop
>>> which occasionally checks a queue for requests from other threads (at
>>> least,
>>> I think that's how it works).
>>
>> What I'm wrestling with is the following.  Say I make a GUI library.
>> As author of the GUI library I discover issues like this where the
>> library code needs to execute on the "main" thread.  Users of the
>> library expect the typical Haskell environment where you can't tell
>> the difference between threads, and you fork at will.  How can I make
>> sure my library works from GHC (with arbitrary user threads) and from
>> GHCI?
>>
>> As John Lato points out in his email lots of people bump into this
>> without realizing it and don't understand what the problem is.  We can
>> try our best to educate everyone, but I have this sense that we could
>> also do a better job of providing primitives to make it so that code
>> will run on the main thread regardless of how people invoke the
>> library.
>>
>> In my specific case (Cocoa on OSX), it is possible for me to use some
>> Cocoa functions to force things to run on the main thread.  From what
>> I've read Cocoa uses pthreads to implement this. I was hoping we could
>> expose something from the RTS code in Control.Concurrent so that it's
>> part of an "official" Haskell API that library writers can assume.
>>
>> Judging by this SO question, it's easier to implement this in Haskell
>> on top of pthreads than to implement it in C (here I'm assuming GHC's
>> RTS uses pthreads, but I've never checked):
>>
>> http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread
>>
>> In fact, the it sounds like what Gtk2hs is doing with the postGUI
>> functions.
>
> Right, but usually the way this is implemented is with some cooperation from
> the main thread.  That SO answer explains it - the main thread runs some
> kind of loop that periodically checks for requests from other threads and
> services them.  I expect that's how it works on Cocoa.
> So you can't just do this from a library - the main thread has to be in on
> the game.

Yes.  From my perspective (that of a library writer) that's what makes
this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
perspective it's tricky too.

> I suppose you might wonder whether the GHC RTS could implement
> runInMainThread by preempting the main thread and running some different
> code on it.

Yes, that's roughly what I was wondering about.

>  In theory that's possible, but whether it's a good idea or not
> is a different matter!  I think it amounts to the same thing as the gtk2hs
> folks have been asking for - multiple Haskell threads bound to the same OS
> thread.

I'm starting to realize that I don't understand the GHC threading
model very well :)  I thought that was already possible.  I may be
mixing GHC's thread model up with other language imp

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/2011 15:42, Jason Dagit wrote:

On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:

On 06/07/2011 07:37, Jason Dagit wrote:


On Jul 5, 2011 1:04 PM, "Jason Dagit"mailto:dag...@gmail.com>>  wrote:
  >
  >  On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynaghmailto:ig...@earth.li>>  wrote:
  >  >  On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
  >  >>
  >  >>  In GHCi it's a different matter, because the main thread is running
  >  >>  GHCi itself, and all the expressions/statements typed at the prompt
  >  >>  are run in forkIO'd threads (a new one for each statement, in fact).
  >  >>  If you want a way to run command-line operations in the main thread,
  >  >>  please submit a feature request.  I'm not sure it can be done, but
  >  >>  I'll look into it.
  >  >
  >  >  We already have a way: -fno-ghci-sandbox
  >
  >  I've removed all my explicit attempts to forkIO/forkOS and passed the
  >  command line flag you mention.  I just tried this but it doesn't
  >  change the behavior in my example.

I tried it again and discovered that due to an argument parsing bug in
cabal-dev that the flag was not passed correctly. I explicitly passed it
and verified that it works. Thanks for the workaround. By the way, I did
look at the user guide for options like this and didn't see it. Which
part of the manual is it in?

Can I still make a feature request for a function to make code run on
the original thread? My reasoning is that the code which needs to run on
the main thread may appear in a library in which case the developer has
no control over how ghc is invoked.


I'm not sure how that would work.  The programmer is in control of what the
main thread does, not GHC.  So in order to implement some mechanism to run
code on the main thread, we would need some cooperation from the main thread
itself.  For example, in gtk2hs the main thread runs an event handler loop
which occasionally checks a queue for requests from other threads (at least,
I think that's how it works).


What I'm wrestling with is the following.  Say I make a GUI library.
As author of the GUI library I discover issues like this where the
library code needs to execute on the "main" thread.  Users of the
library expect the typical Haskell environment where you can't tell
the difference between threads, and you fork at will.  How can I make
sure my library works from GHC (with arbitrary user threads) and from
GHCI?

As John Lato points out in his email lots of people bump into this
without realizing it and don't understand what the problem is.  We can
try our best to educate everyone, but I have this sense that we could
also do a better job of providing primitives to make it so that code
will run on the main thread regardless of how people invoke the
library.

In my specific case (Cocoa on OSX), it is possible for me to use some
Cocoa functions to force things to run on the main thread.  From what
I've read Cocoa uses pthreads to implement this. I was hoping we could
expose something from the RTS code in Control.Concurrent so that it's
part of an "official" Haskell API that library writers can assume.

Judging by this SO question, it's easier to implement this in Haskell
on top of pthreads than to implement it in C (here I'm assuming GHC's
RTS uses pthreads, but I've never checked):
http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

In fact, the it sounds like what Gtk2hs is doing with the postGUI functions.


Right, but usually the way this is implemented is with some cooperation 
from the main thread.  That SO answer explains it - the main thread runs 
some kind of loop that periodically checks for requests from other 
threads and services them.  I expect that's how it works on Cocoa.
So you can't just do this from a library - the main thread has to be in 
on the game.


I suppose you might wonder whether the GHC RTS could implement 
runInMainThread by preempting the main thread and running some different 
code on it.  In theory that's possible, but whether it's a good idea or 
not is a different matter!  I think it amounts to the same thing as the 
gtk2hs folks have been asking for - multiple Haskell threads bound to 
the same OS thread.  runInMainThread then becomes the same as forking a 
temporary new thread bound to the main OS thread, or temporarily binding 
the current thread to the main OS thread.  If the main OS thread is off 
making a foreign call (e.g. in the GUI library's main loop) then it 
can't run any other Haskell threads anyway, and then I have to figure 
out what to do with all these Haskell threads waiting for their bound OS 
thread to come back from the foreign call.  My guess is that all this 
would be pretty complex to implement.


Still, I'm all for making things easier somehow.  At the least, we 
should have good diagnostics when you're using GHCi and this goes wrong. 
 Although I'm not sure how to do that, I think it's really something 
the gtk2hs or Cocoa binding needs to im

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:
> On 06/07/2011 07:37, Jason Dagit wrote:
>>
>> On Jul 5, 2011 1:04 PM, "Jason Dagit" > > wrote:
>>  >
>>  > On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh > > wrote:
>>  > > On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
>>  > >>
>>  > >> In GHCi it's a different matter, because the main thread is running
>>  > >> GHCi itself, and all the expressions/statements typed at the prompt
>>  > >> are run in forkIO'd threads (a new one for each statement, in fact).
>>  > >> If you want a way to run command-line operations in the main thread,
>>  > >> please submit a feature request.  I'm not sure it can be done, but
>>  > >> I'll look into it.
>>  > >
>>  > > We already have a way: -fno-ghci-sandbox
>>  >
>>  > I've removed all my explicit attempts to forkIO/forkOS and passed the
>>  > command line flag you mention.  I just tried this but it doesn't
>>  > change the behavior in my example.
>>
>> I tried it again and discovered that due to an argument parsing bug in
>> cabal-dev that the flag was not passed correctly. I explicitly passed it
>> and verified that it works. Thanks for the workaround. By the way, I did
>> look at the user guide for options like this and didn't see it. Which
>> part of the manual is it in?
>>
>> Can I still make a feature request for a function to make code run on
>> the original thread? My reasoning is that the code which needs to run on
>> the main thread may appear in a library in which case the developer has
>> no control over how ghc is invoked.
>
> I'm not sure how that would work.  The programmer is in control of what the
> main thread does, not GHC.  So in order to implement some mechanism to run
> code on the main thread, we would need some cooperation from the main thread
> itself.  For example, in gtk2hs the main thread runs an event handler loop
> which occasionally checks a queue for requests from other threads (at least,
> I think that's how it works).

What I'm wrestling with is the following.  Say I make a GUI library.
As author of the GUI library I discover issues like this where the
library code needs to execute on the "main" thread.  Users of the
library expect the typical Haskell environment where you can't tell
the difference between threads, and you fork at will.  How can I make
sure my library works from GHC (with arbitrary user threads) and from
GHCI?

As John Lato points out in his email lots of people bump into this
without realizing it and don't understand what the problem is.  We can
try our best to educate everyone, but I have this sense that we could
also do a better job of providing primitives to make it so that code
will run on the main thread regardless of how people invoke the
library.

In my specific case (Cocoa on OSX), it is possible for me to use some
Cocoa functions to force things to run on the main thread.  From what
I've read Cocoa uses pthreads to implement this. I was hoping we could
expose something from the RTS code in Control.Concurrent so that it's
part of an "official" Haskell API that library writers can assume.

Judging by this SO question, it's easier to implement this in Haskell
on top of pthreads than to implement it in C (here I'm assuming GHC's
RTS uses pthreads, but I've never checked):
http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

In fact, the it sounds like what Gtk2hs is doing with the postGUI functions.

Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Wed, Jul 6, 2011 at 2:20 AM, Simon Marlow  wrote:
> On 05/07/2011 20:38, Jason Dagit wrote:
>>
>> On Tue, Jul 5, 2011 at 12:11 PM, Simon Marlow  wrote:
>>>
>>> On 04/07/11 06:02, Jason Dagit wrote:

 Hello,

 I'm trying to get some GUI code working on OSX and numerous forums
 around the internet keep reiterating that on OSX to correctly handle
 GUI events you need to use the original thread allocated to your
 process to check for events and to call the Cocoa framework
 functionality.  Specifically, using a secondary thread (even a bound
 thread) is not sufficient with the Cocoa framework.

 I looked at the threading documentation in Control.Concurrent for GHC
 and it's not clear to me if this is even possible with GHC without
 restricting to the non-threaded RTS.  This means that using the GUI
 library from GHCI is not an option and using multiple OS threads in
 the final application is also not possible.  This means that some FFI
 libraries will be unusable.
>>>
>>> In a compiled program, the main thread is a bound thread, bound to the
>>> main
>>> OS thread of the process (i.e. the GUI thread in your case).  So you can
>>> safely make Cocoa calls using the main thread of your compiled Haskell
>>> program, and from other threads if you add some way to forward operations
>>> to
>>> the main thread, like gtk2hs's postGUI.
>>
>> Is my understanding correct that this is only the case for the
>> non-threaded RTS?
>
> No - I'm talking about the threaded RTS here.  It's trivially true of the
> non-threaded RTS too, because there's only one OS thread.
>
>>  If so, what do you do when you need to use the
>> threaded RTS?  My test was to check if the main thread was bound when
>> compiling with -threaded.  I got the impression that I couldn't
>> guarantee that the code was running on the original thread.
>
> You do have that guarantee for the main thread.  Could you point out the
> docs that gave you the opposite impression - I'll see if we can improve
> them.

I did read this section:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#g:8

And I played with some of the functions there.  What I didn't take
away from this was the guarantee that main runs on the original OS
thread.  I had the impression that it was running from some bound
thread, possibly created via runInBoundThread.  I think that ghc and
ghci are quite different in this regard.  It would probably be good to
mention that distinction.

Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[John Lato]

Message: 23

> Date: Wed, 06 Jul 2011 10:14:56 +0100
> From: Simon Marlow 
> Subject: Re: [Haskell-cafe] How to ensure code executes in the context
>of a    specific OS thread?
> To: Jason Dagit , cvs-...@haskell.org,Haskell
> Cafe
>
> Message-ID: <4e142790.8090...@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 05/07/2011 20:33, Ian Lynagh wrote:
> > On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
> >>
> >> In GHCi it's a different matter, because the main thread is running
> >> GHCi itself, and all the expressions/statements typed at the prompt
> >> are run in forkIO'd threads (a new one for each statement, in fact).
> >> If you want a way to run command-line operations in the main thread,
> >> please submit a feature request.  I'm not sure it can be done, but
> >> I'll look into it.
> >
> > We already have a way: -fno-ghci-sandbox
>
> Aha, I'd forgotten about that!  Thanks Ian.
>
> Simon
>

IIRC a lot of people have had trouble running GUI apps from within GHCi on
OS X, whether they're GLUT, Gtk2hs, WxHaskell, or native, and several users
consider this a large obstacle.  I know that I haven't been successful with
gtk2hs.  However, at this suggestion I just tried running a gtk2hs app I'm
developing with the -fno-ghci-sandbox flag, and it worked perfectly.

Thanks very much, Ian.

John L.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/2011 07:37, Jason Dagit wrote:


On Jul 5, 2011 1:04 PM, "Jason Dagit" mailto:dag...@gmail.com>> wrote:
 >
 > On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh mailto:ig...@earth.li>> wrote:
 > > On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
 > >>
 > >> In GHCi it's a different matter, because the main thread is running
 > >> GHCi itself, and all the expressions/statements typed at the prompt
 > >> are run in forkIO'd threads (a new one for each statement, in fact).
 > >> If you want a way to run command-line operations in the main thread,
 > >> please submit a feature request.  I'm not sure it can be done, but
 > >> I'll look into it.
 > >
 > > We already have a way: -fno-ghci-sandbox
 >
 > I've removed all my explicit attempts to forkIO/forkOS and passed the
 > command line flag you mention.  I just tried this but it doesn't
 > change the behavior in my example.

I tried it again and discovered that due to an argument parsing bug in
cabal-dev that the flag was not passed correctly. I explicitly passed it
and verified that it works. Thanks for the workaround. By the way, I did
look at the user guide for options like this and didn't see it. Which
part of the manual is it in?

Can I still make a feature request for a function to make code run on
the original thread? My reasoning is that the code which needs to run on
the main thread may appear in a library in which case the developer has
no control over how ghc is invoked.


I'm not sure how that would work.  The programmer is in control of what 
the main thread does, not GHC.  So in order to implement some mechanism 
to run code on the main thread, we would need some cooperation from the 
main thread itself.  For example, in gtk2hs the main thread runs an 
event handler loop which occasionally checks a queue for requests from 
other threads (at least, I think that's how it works).


Cheers,
Simon



The alternative appears to be context specific workarounds. I think that
a general solution, if possible, will make gui libraries easier to
develop for Ghc.  I'm hooping it's as simple as exposing a pthreads call.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 05/07/2011 20:38, Jason Dagit wrote:

On Tue, Jul 5, 2011 at 12:11 PM, Simon Marlow  wrote:

On 04/07/11 06:02, Jason Dagit wrote:


Hello,

I'm trying to get some GUI code working on OSX and numerous forums
around the internet keep reiterating that on OSX to correctly handle
GUI events you need to use the original thread allocated to your
process to check for events and to call the Cocoa framework
functionality.  Specifically, using a secondary thread (even a bound
thread) is not sufficient with the Cocoa framework.

I looked at the threading documentation in Control.Concurrent for GHC
and it's not clear to me if this is even possible with GHC without
restricting to the non-threaded RTS.  This means that using the GUI
library from GHCI is not an option and using multiple OS threads in
the final application is also not possible.  This means that some FFI
libraries will be unusable.


In a compiled program, the main thread is a bound thread, bound to the main
OS thread of the process (i.e. the GUI thread in your case).  So you can
safely make Cocoa calls using the main thread of your compiled Haskell
program, and from other threads if you add some way to forward operations to
the main thread, like gtk2hs's postGUI.


Is my understanding correct that this is only the case for the
non-threaded RTS?


No - I'm talking about the threaded RTS here.  It's trivially true of 
the non-threaded RTS too, because there's only one OS thread.



 If so, what do you do when you need to use the
threaded RTS?  My test was to check if the main thread was bound when
compiling with -threaded.  I got the impression that I couldn't
guarantee that the code was running on the original thread.


You do have that guarantee for the main thread.  Could you point out the 
docs that gave you the opposite impression - I'll see if we can improve 
them.


Cheers,
Simon

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 05/07/2011 20:33, Ian Lynagh wrote:

On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:


In GHCi it's a different matter, because the main thread is running
GHCi itself, and all the expressions/statements typed at the prompt
are run in forkIO'd threads (a new one for each statement, in fact).
If you want a way to run command-line operations in the main thread,
please submit a feature request.  I'm not sure it can be done, but
I'll look into it.


We already have a way: -fno-ghci-sandbox


Aha, I'd forgotten about that!  Thanks Ian.

Simon

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Jul 5, 2011 1:04 PM, "Jason Dagit"  wrote:
>
> On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh  wrote:
> > On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
> >>
> >> In GHCi it's a different matter, because the main thread is running
> >> GHCi itself, and all the expressions/statements typed at the prompt
> >> are run in forkIO'd threads (a new one for each statement, in fact).
> >> If you want a way to run command-line operations in the main thread,
> >> please submit a feature request.  I'm not sure it can be done, but
> >> I'll look into it.
> >
> > We already have a way: -fno-ghci-sandbox
>
> I've removed all my explicit attempts to forkIO/forkOS and passed the
> command line flag you mention.  I just tried this but it doesn't
> change the behavior in my example.

I tried it again and discovered that due to an argument parsing bug in
cabal-dev that the flag was not passed correctly. I explicitly passed it and
verified that it works. Thanks for the workaround. By the way, I did look at
the user guide for options like this and didn't see it. Which part of the
manual is it in?

Can I still make a feature request for a function to make code run on the
original thread? My reasoning is that the code which needs to run on the
main thread may appear in a library in which case the developer has no
control over how ghc is invoked.

The alternative appears to be context specific workarounds. I think that a
general solution, if possible, will make gui libraries easier to develop for
Ghc.  I'm hooping it's as simple as exposing a pthreads call.

Thanks,
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh  wrote:
> On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
>>
>> In GHCi it's a different matter, because the main thread is running
>> GHCi itself, and all the expressions/statements typed at the prompt
>> are run in forkIO'd threads (a new one for each statement, in fact).
>> If you want a way to run command-line operations in the main thread,
>> please submit a feature request.  I'm not sure it can be done, but
>> I'll look into it.
>
> We already have a way: -fno-ghci-sandbox

I've removed all my explicit attempts to forkIO/forkOS and passed the
command line flag you mention.  I just tried this but it doesn't
change the behavior in my example.

Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Tue, Jul 5, 2011 at 12:11 PM, Simon Marlow  wrote:
> On 04/07/11 06:02, Jason Dagit wrote:
>>
>> Hello,
>>
>> I'm trying to get some GUI code working on OSX and numerous forums
>> around the internet keep reiterating that on OSX to correctly handle
>> GUI events you need to use the original thread allocated to your
>> process to check for events and to call the Cocoa framework
>> functionality.  Specifically, using a secondary thread (even a bound
>> thread) is not sufficient with the Cocoa framework.
>>
>> I looked at the threading documentation in Control.Concurrent for GHC
>> and it's not clear to me if this is even possible with GHC without
>> restricting to the non-threaded RTS.  This means that using the GUI
>> library from GHCI is not an option and using multiple OS threads in
>> the final application is also not possible.  This means that some FFI
>> libraries will be unusable.
>
> In a compiled program, the main thread is a bound thread, bound to the main
> OS thread of the process (i.e. the GUI thread in your case).  So you can
> safely make Cocoa calls using the main thread of your compiled Haskell
> program, and from other threads if you add some way to forward operations to
> the main thread, like gtk2hs's postGUI.

Is my understanding correct that this is only the case for the
non-threaded RTS?  If so, what do you do when you need to use the
threaded RTS?  My test was to check if the main thread was bound when
compiling with -threaded.  I got the impression that I couldn't
guarantee that the code was running on the original thread.

>
> In GHCi it's a different matter, because the main thread is running GHCi
> itself, and all the expressions/statements typed at the prompt are run in
> forkIO'd threads (a new one for each statement, in fact).  If you want a way
> to run command-line operations in the main thread, please submit a feature
> request.  I'm not sure it can be done, but I'll look into it.

I'll try Ian's suggestion of -fno-ghci-sandbox when I get a chance.

Thanks,
Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Ian Lynagh]

On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
> 
> In GHCi it's a different matter, because the main thread is running
> GHCi itself, and all the expressions/statements typed at the prompt
> are run in forkIO'd threads (a new one for each statement, in fact).
> If you want a way to run command-line operations in the main thread,
> please submit a feature request.  I'm not sure it can be done, but
> I'll look into it.

We already have a way: -fno-ghci-sandbox


Thanks
Ian


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 04/07/11 06:02, Jason Dagit wrote:

Hello,

I'm trying to get some GUI code working on OSX and numerous forums
around the internet keep reiterating that on OSX to correctly handle
GUI events you need to use the original thread allocated to your
process to check for events and to call the Cocoa framework
functionality.  Specifically, using a secondary thread (even a bound
thread) is not sufficient with the Cocoa framework.

I looked at the threading documentation in Control.Concurrent for GHC
and it's not clear to me if this is even possible with GHC without
restricting to the non-threaded RTS.  This means that using the GUI
library from GHCI is not an option and using multiple OS threads in
the final application is also not possible.  This means that some FFI
libraries will be unusable.


In a compiled program, the main thread is a bound thread, bound to the 
main OS thread of the process (i.e. the GUI thread in your case).  So 
you can safely make Cocoa calls using the main thread of your compiled 
Haskell program, and from other threads if you add some way to forward 
operations to the main thread, like gtk2hs's postGUI.


In GHCi it's a different matter, because the main thread is running GHCi 
itself, and all the expressions/statements typed at the prompt are run 
in forkIO'd threads (a new one for each statement, in fact).  If you 
want a way to run command-line operations in the main thread, please 
submit a feature request.  I'm not sure it can be done, but I'll look 
into it.


Cheers,
Simon



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[David Pollak]

On Sun, Jul 3, 2011 at 10:02 PM, Jason Dagit  wrote:

> Hello,
>
> I'm trying to get some GUI code working on OSX and numerous forums
> around the internet keep reiterating that on OSX to correctly handle
> GUI events you need to use the original thread allocated to your
> process to check for events and to call the Cocoa framework
> functionality.  Specifically, using a secondary thread (even a bound
> thread) is not sufficient with the Cocoa framework.
>
> I looked at the threading documentation in Control.Concurrent for GHC
> and it's not clear to me if this is even possible with GHC without
> restricting to the non-threaded RTS.  This means that using the GUI
> library from GHCI is not an option and using multiple OS threads in
> the final application is also not possible.  This means that some FFI
> libraries will be unusable.
>
> My main question is, is there a way around this so that I could, for
> example, use the library from GHCI?
>
> My second question is, if there is no current workaround then how can
> we remedy this situation?  It seems like there could be an api
> function like:
> runOnOriginalThread :: IO a -> IO a
>

I've got some code in https://github.com/dpp/LispHaskellIPad that uses an
FFI call into ObjC code that invokes a function on the UI thread.

In Haskell:

runOnMain :: IO () -> IO ()
runOnMain todo = do
  func <- funky
  dispatchFunc func
  where funky =  mkStrCB $ \v -> do
   todo

And in ObjC:

void dispatchFunc(void (*fp)(void*)) {
// dispatch_async_f(dispatch_get_main_queue(), NULL, fp);
id runner = [[PerformOMatic alloc] init];
[runner setFunc:fp];
[runner run];
}

And:

#import "PerformOMatic.h"


@implementation PerformOMatic
- (void)run {
[self performSelectorOnMainThread:@selector(reallyDoIt:) withObject:self
waitUntilDone:TRUE];
}

- (void)reallyDoIt:(id)ignore {
whatToDo(NULL);
releaseMe(whatToDo);
[self dealloc];
}

- (void)setFunc:(void *)func {
whatToDo = func;
}

@end


Pardon the extremely ugly code, I'm a Haskell newbie and my ObjC skills are
20 years old.


>
> This function would be similar to runInBoundThread except it would be
> guaranteed to run on the original thread allocated to the ghc/ghci
> process.  I believe the above primitive would be sufficient.
>
> I'll worry about filing a bug or making a libraries proposal after I
> have a better understanding of what must be done.
>
> Thanks,
> Jason
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Lift, the simply functional web framework http://liftweb.net
Simply Lift http://simply.liftweb.net
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Edward Z. Yang]

Sounds like something that could use a GHC Trac feature request.

Edward

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Felipe Almeida Lessa]

On Mon, Jul 4, 2011 at 2:38 AM, Jason Dagit  wrote:
> (I believe the way the FFI works I'll have
> to make a new wrapper for each "thing" because I can't directly call
> objective-c).

Probably, yes.

> I suppose I should try adding wrappers around all the GLFW functions
> so that it sends the request over to the main thread and see if it
> solves my problem.  The downside is that it would be a lot of wrapper
> code and it would be nice to have solution that other libraries can
> use.

Do you mean, on each function of GLFW's API?  Usually it's better to
call postGUISync/postGUIAsync alikes with the largest number of
function calls possible because (a) of the overhead (especially
postGUISync's) and (b) it's safer to assume that postGUIAsyncs can be
reordered.

That is, if you need to call 'do {foo; bar}', instead of using 'do
{fooS; barS}' where these are wrapped functions, call 'postGUISync $
do {foo; bar}'.  This solution is general in the sense that you only
have to code it once for everything Cocoa-related.

Cheers! =)

-- 
Felipe.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Sun, Jul 3, 2011 at 10:22 PM, Felipe Almeida Lessa
 wrote:
> On Mon, Jul 4, 2011 at 2:02 AM, Jason Dagit  wrote:
>> My second question is, if there is no current workaround then how can
>> we remedy this situation?  It seems like there could be an api
>> function like:
>> runOnOriginalThread :: IO a -> IO a
>
> Isn't there something on Cocoa that would allow you to implement this
> function?  For example, to implement postGUISync [1] on Gtk2Hs, Glib's
> g_idle_add() [2] is used [3].  To implement Gtk.Application.Invoke [4]
> on Gtk#, Glib's g_timeout_add with a timeout of 0 seconds is used [6].
>  In other words, some way of running an arbitrary function inside
> Cocoa's event loop.

There are a few objective-c specific ways of sending something to the
right thread.  I was hoping to find something a bit more general and
easier to call from Haskell (I believe the way the FFI works I'll have
to make a new wrapper for each "thing" because I can't directly call
objective-c).

I suppose I should try adding wrappers around all the GLFW functions
so that it sends the request over to the main thread and see if it
solves my problem.  The downside is that it would be a lot of wrapper
code and it would be nice to have solution that other libraries can
use.

Thanks for the idea.

Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Sun, Jul 3, 2011 at 10:31 PM, David Barbour  wrote:
>
> On Jul 3, 2011, Jason Dagit  wrote:
>>
>> to correctly handle GUI events you need to use the original thread
>> allocated to your process to check for events and to call the Cocoa
>> framework functionality.
>>
>> I looked at the threading documentation in Control.Concurrent for GHC and
>> it's not clear to me if this is even possible with GHC without restricting
>> to the non-threaded RTS.
>
> The 'main' thread in GHC is the bound thread initially allocated to the
> process.

That doesn't seem to be the case for GHCI.

> You can easily establish an event-loop in the main thread, and feed
> events from other threads. Consider using Control.Concurrent.Chan.
> If you need feedback, things get a bit trickier because you'll have special
> cases based on whether you're starting in the main thread.

Yes, that might work for compiled programs.  What about GHCI?

Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[David Barbour]

On Jul 3, 2011, Jason Dagit  wrote:

> to correctly handle GUI events you need to use the original thread
> allocated to your process to check for events and to call the Cocoa
> framework functionality.
>
> I looked at the threading documentation in Control.Concurrent for GHC and
> it's not clear to me if this is even possible with GHC without restricting
> to the non-threaded RTS.
>

The 'main' thread in GHC is the bound thread initially allocated to the
process. You can easily establish an event-loop in the main thread, and feed
events from other threads. Consider using Control.Concurrent.Chan.

If you need feedback, things get a bit trickier because you'll have special
cases based on whether you're starting in the main thread.

Regards,

Dave
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Sun, Jul 3, 2011 at 10:02 PM, Jason Dagit  wrote:
> Hello,
>
> I'm trying to get some GUI code working on OSX and numerous forums
> around the internet keep reiterating that on OSX to correctly handle
> GUI events you need to use the original thread allocated to your
> process to check for events and to call the Cocoa framework
> functionality.  Specifically, using a secondary thread (even a bound
> thread) is not sufficient with the Cocoa framework.

Context for others:

People explaining that you can't use the secondary thread for GUI operations:
http://www.cocoabuilder.com/archive/cocoa/298918-multithread-window-event-runloop-headache.html
http://old.nabble.com/Weird-Carbon%3A-gestalt%3A-wxPython-issue-bug-td27456897.html
http://www.cocoabuilder.com/archive/cocoa/205803-event-loop-in-secondary-thread-nibless-cocoa.html
http://forums.libsdl.org/viewtopic.php?t=6281&sid=ec818336d68f9797090719b3c5916c21
http://www.cocoabuilder.com/archive/cocoa/292830-nstimer-not-working-in-multithreaded-application.html
http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html
http://www.cocoabuilder.com/archive/cocoa/152947-cocoa-multithreading-in-terrible-idea-isn-it.html

Cocoa provides several ways to run things on the "main thread" (same
as I meant when I said original thread):
http://blog.jayway.com/2010/03/30/performing-any-selector-on-the-main-thread/
http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/

Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Felipe Almeida Lessa]

On Mon, Jul 4, 2011 at 2:02 AM, Jason Dagit  wrote:
> My second question is, if there is no current workaround then how can
> we remedy this situation?  It seems like there could be an api
> function like:
> runOnOriginalThread :: IO a -> IO a

Isn't there something on Cocoa that would allow you to implement this
function?  For example, to implement postGUISync [1] on Gtk2Hs, Glib's
g_idle_add() [2] is used [3].  To implement Gtk.Application.Invoke [4]
on Gtk#, Glib's g_timeout_add with a timeout of 0 seconds is used [6].
 In other words, some way of running an arbitrary function inside
Cocoa's event loop.

Cheers! =)

[1] 
http://hackage.haskell.org/packages/archive/gtk/0.12.0/doc/html/Graphics-UI-Gtk-General-General.html#v:postGUISync
[2] 
http://developer.gnome.org/glib/2.28/glib-The-Main-Event-Loop.html#g-idle-add
[3] 
http://hackage.haskell.org/packages/archive/gtk/0.12.0/doc/html/src/Graphics-UI-Gtk-General-General.html#postGUISync
[4] (link seems broken)
http://www.go-mono.com/docs/monodoc.ashx?link=M%3aGtk.Application.Invoke(System.EventHandler)
[5] 
http://developer.gnome.org/glib/2.28/glib-The-Main-Event-Loop.html#g-timeout-add
[6] https://github.com/mono/gtk-sharp/blob/master/gtk/Application.cs#L200

-- 
Felipe.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

Hello,

I'm trying to get some GUI code working on OSX and numerous forums
around the internet keep reiterating that on OSX to correctly handle
GUI events you need to use the original thread allocated to your
process to check for events and to call the Cocoa framework
functionality.  Specifically, using a secondary thread (even a bound
thread) is not sufficient with the Cocoa framework.

I looked at the threading documentation in Control.Concurrent for GHC
and it's not clear to me if this is even possible with GHC without
restricting to the non-threaded RTS.  This means that using the GUI
library from GHCI is not an option and using multiple OS threads in
the final application is also not possible.  This means that some FFI
libraries will be unusable.

My main question is, is there a way around this so that I could, for
example, use the library from GHCI?

My second question is, if there is no current workaround then how can
we remedy this situation?  It seems like there could be an api
function like:
runOnOriginalThread :: IO a -> IO a

This function would be similar to runInBoundThread except it would be
guaranteed to run on the original thread allocated to the ghc/ghci
process.  I believe the above primitive would be sufficient.

I'll worry about filing a bug or making a libraries proposal after I
have a better understanding of what must be done.

Thanks,
Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe