[fxruby-users] Re: FXRuby and Threads (was: radiobuttons are weird in 1.2.x series)

Bil bil.bas at virgin.net
Thu Jul 22 12:30:18 EDT 2004

*********** REPLY SEPARATOR  ***********

On 22/07/2004 at 14:01 lyle at knology.net wrote:

>On Thu, 22 Jul 2004 14:47:47 +0100, "Bil" <bil.bas at virgin.net> wrote :
>> Err, well it does work, though it does not require the background thread
>to run very fast at all. The application is a prototype of a board-game
>engine. The server is a regular threaded Ruby application (no FXRuby at
>all). The client is obviously an FXRuby app.
>Wait, are we talking about two different Ruby processes here? I mean, do we
>have a single-threaded client (which is a FXRuby app) running in process A,
>and a multi-threaded server (a non-FXRuby app) running in process B? If so,
>yeah, that should work.

The server is just acting as a message router and is a console app. The client, however, runs a single extra thread to read messages from the server concurrently with being an FXRuby application.
In the client we have:
Read thread created when client connects to the server:

    @sock = TCPSocket.new(host, PORT)
    Thread.new do
        loop do
          # Queues up messages until they can be handled by client
          message = @sock.readMsg
          @queueMutex.synchronize {
            @messageQueue.push message

During the FXRuby chore the queue is checked and a single message is processed, if available:

 def nextMessage
    # Pull off the first message (if there is one)
    if @queueMutex.try_lock
      message = @messageQueue.shift
      message = nil

    return message

I checked it again, and with threadsDisabled the FXDataTargets/statusbar work perfectly and communication between clients is consistently instantaneous as far as my eyes can see (both clients and server on one machine). E.g. The Xs and Os in TIC-TAC-TOE seem to appear right away when placed on the opponent's client (at least until I got bored of playing it *8-)* ).

>I was talking about a single Ruby application (process) that uses FXRuby
>has multiple threads. For an example, see the groupbox.rb example program
>that comes with FXRuby. There should be a little clock in the lower
>right-hand corner that's being updated by a thread, i.e. threads support is
>"enabled" for that particular program.

Hmm, that groupbox.rb code breaks "correctly" (doesn't update time very often) when application.disableThreads is called.

Do you mean an external thread that *directly* affects FXRuby components? Mine does not interface with FXRuby at all - it merely communicates via a synchonized queue and it is the FXRuby process (via a chore) that does the alteration. Perhaps that is it? *shrug*


More information about the fxruby-users mailing list