[FR-devel] FW: Ruby threading and GUI toolkits

[Rich Kilmer]

My threading issues with GUI toolkits are based on working on the mswin32
build.  I just tried the cygwin build with fox and everything works great.
If Lyle addressing this problem I think we will not have an issue with
mixing threads under the FreeBASE plugin architecture.

Sorry for misinformation or the spreading of false rumors ;-)

Rich

-----Original Message-----
From: Rich Kilmer [mailto:address@hidden
Sent: Saturday, February 16, 2002 1:05 PM
To: ruby-talk ML
Subject: RE: Ruby threading and GUI toolkits


Well, I actually apologize.

What I need to do is be able to start <n> number of Threads before the UI
mainloop and then start that mainloop in its own thread.  I have been trying
this on Win32 on the mswin32/1.7.2 (not cygwin) build.  I just tried a slew
of stuff under cygwin and it works great (tk, fox...have not tried gtk).

I tried VRuby.  It ONLY lets you set an idle proc but starves other threads.
This was the first UI toolkit I used and gave me a false first impression on
other toolkits.

I tried Fox. It works great under cygwin..but blows up under the mswin32
build when other threads are present.  I contacted Lyle about it...and he is
going to look into it.

I have not run tk under mswin32...but I'll give it a try.

Just needed more exploration before asking ;-)

-Rich

> -----Original Message-----
> From: cix [mailto:address@hidden
> Sent: Saturday, February 16, 2002 11:23 AM
> To: ruby-talk ML
> Subject: Re: Ruby threading and GUI toolkits
>
>
> On Saturday 16 February 2002 16:17, you wrote:
> > I've encountered a bit of a dilemma.  I need to have a GUI
> application with
> > background threads handling communications (tcp, etc).  With the GUI
> > toolkits I have seen you set them up (build windows/widgets)
> then you enter
> > a message loop, and it locks the whole Ruby process (all other
> Ruby threads
> > are "starved").  I know Lyle has something that lets this work
> on Fox (kind
> > of...1.7 issues) but I was just wondering if anyone had any
> experience with
> > allowing this GUI message loop to NOT lock up Ruby threads?
> Are there any
> > general strategies we could use to enable this across all of the GUI
> > toolkits?
> >
> > -Rich
> Hi Rich,
> I do not understand exactly your question. The reason I write is that
> I have just written a small program which is a talk-like application.
> Each client has two threads, one getting charactes from the keybord,
> displayng them to the 'in' window (Tk text) and sending them to a socket,
> the other one reading  from the socket and displaying to the 'out' window.
> The user can see the peer's messages while writing his owns.
> If this behaviour is what you are talking about, could you describe the
> problem a little bit more in detail so that I can help in solving it?
> Bye,
> cix