From: D.V. <dav...@gm...> - 2011-09-02 08:41:55
|
Bonjour List ! I am writing a program that is supposed to listen to a tcp port, and when a client connects, update a UI done with wxHaskell. Since wxHaskell is not compatible with multiple threads, I am not sure how to do this. an idea I have is to - forkOS a thread which will do the network part. - when a message is sent from a client, write it to a channel - on the other thread, have a wxHaskell timer check periodically if a new message is available, update the UI if needed. I've tried it and it looks like it's working, but I anyone has some remark I'm interested. David. |
From: <mac...@gm...> - 2011-09-02 14:03:35
|
There is indeed a claim in wxHaskell FAQ that it is incompatible with Haskell threads. I have, however, used threads spawned with forkIO to update wxHaskell GUI in toy apps, without any ill effects. Examples: http://mmakowski.com/wiki/tech:haskell_mvc https://github.com/mmakowski/habaz I'd be interested to learn how the incompatibility can manifest itself -- if there indeed is any. Regards, Maciek On Fri, Sep 2, 2011 at 9:41 AM, D.V. <dav...@gm...> wrote: > Bonjour List ! > > I am writing a program that is supposed to listen to a tcp port, and > when a client connects, > update a UI done with wxHaskell. > > Since wxHaskell is not compatible with multiple threads, I am not sure > how to do this. > > an idea I have is to > > - forkOS a thread which will do the network part. > - when a message is sent from a client, write it to a channel > - on the other thread, have a wxHaskell timer check periodically if a > new message is available, update the UI if needed. > > I've tried it and it looks like it's working, but I anyone has some > remark I'm interested. > > David. > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > wxhaskell-users mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users > |
From: Eric Y. K. <eri...@gm...> - 2011-09-02 14:21:28
|
On Fri, Sep 02, 2011 at 15:03:28 +0100, mac...@gm... wrote: > There is indeed a claim in wxHaskell FAQ that it is incompatible with > Haskell threads. I have, however, used threads spawned with forkIO to > update wxHaskell GUI in toy apps, without any ill effects. Examples: > > http://mmakowski.com/wiki/tech:haskell_mvc > https://github.com/mmakowski/habaz > > I'd be interested to learn how the incompatibility can manifest itself > -- if there indeed is any. It's worth noting this entry from the wxWidgets FAQ: wxWidgets (like most GUI toolkits underneath it) is not thread-safe, and handling of GUI components should always be done exclusively in the main thread. This doesn't stop you from doing the non-GUI stuff in other threads though. Was interested to see that the wxHaskell mutable var is just a TVar (from STM?) -- Eric Kow <http://erickow.com> |
From: <mac...@gm...> - 2011-09-02 14:55:14
|
If the only restriction here is that all the GUI updates should happen on the main OS thread, doesn't it mean that Haskell (green) threads spawned through forkIO are fine, because they execute on the same OS thread? Or does wxHaskell introduce additional restrictions? Maciek On Fri, Sep 2, 2011 at 3:21 PM, Eric Y. Kow <eri...@gm...> wrote: > On Fri, Sep 02, 2011 at 15:03:28 +0100, mac...@gm... wrote: >> There is indeed a claim in wxHaskell FAQ that it is incompatible with >> Haskell threads. I have, however, used threads spawned with forkIO to >> update wxHaskell GUI in toy apps, without any ill effects. Examples: >> >> http://mmakowski.com/wiki/tech:haskell_mvc >> https://github.com/mmakowski/habaz >> >> I'd be interested to learn how the incompatibility can manifest itself >> -- if there indeed is any. > > It's worth noting this entry from the wxWidgets FAQ: > > wxWidgets (like most GUI toolkits underneath it) is not thread-safe, and > handling of GUI components should always be done exclusively in the main > thread. > > This doesn't stop you from doing the non-GUI stuff in other threads > though. > > Was interested to see that the wxHaskell mutable var is just a TVar > (from STM?) > > -- > Eric Kow <http://erickow.com> > |
From: Eric Y. K. <eri...@gm...> - 2011-09-02 15:02:30
|
On Fri, Sep 02, 2011 at 15:55:07 +0100, mac...@gm... wrote: > If the only restriction here is that all the GUI updates should happen > on the main OS thread, doesn't it mean that Haskell (green) threads > spawned through forkIO are fine, because they execute on the same OS > thread? Or does wxHaskell introduce additional restrictions? I'm not the best person to ask, but I will note that Haskell's very lightweight threads may be divided up among one or more OS thread (if you enable the multi-threaded runtime). A Haskell thread may also be passed around from one OS thread to another. See the Word of the Month in http://www.well-typed.com/blog/53 -- Eric Kow <http://erickow.com> |