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

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

On 22/07/2004 at 14:01 lyle@knology.net wrote:
>On Thu, 22 Jul 2004 14:47:47 +0100, "Bil"
<bil.bas@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
          }
        end
    end

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
      @queueMutex.unlock
    else
      message = nil
    end

    return message
  end

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
>and
>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*

bil