nanogui: Thread: Another thread question


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Another thread question
From: "Andy Jorde" ####@####.####
Date: 30 Aug 2004 16:02:31 +0100
Message-Id: <F4AD82AD84BF9A41B4318A16F7E40487099A72@bevmail1.symmetricom.com>

OS: Linux
Built with: THREADSAFE=Y

I'm working on an application that relies heavily on FLNX and makes some limited direct calls into NanoX itself. As long as I stay inside the FLNX framework and make these function calls from there (even from signal handlers) everything works fine. But when I start a separate thread and try these calls, the thread gets blocked (or dies, I can't determine that) when it hits the nxGlobalLock mutex.

I'm not calling a complex function, in this specific case it is GrLowerWindow. And the rest of the program happily runs on - it does not get blocked.

Has anyone else run into this, any ideas what's going on?

Thanks in advance - Andy.

Subject: Re: [nanogui] Another thread question
From: "Greg Haerr" ####@####.####
Date: 12 Sep 2004 23:58:38 +0100
Message-Id: <0c2b01c4991b$ba3ec8a0$3eba46a6@winXP>

> I'm working on an application that relies heavily on FLNX and makes some
limited direct calls into NanoX itself. As long as I stay inside the FLNX
framework and make these function calls from there (even from signal
handlers) everything works fine. But when I start a separate thread and try
these calls, the thread gets blocked (or dies, I can't determine that) when
it hits the nxGlobalLock mutex.

> I'm not calling a complex function, in this specific case it is
GrLowerWindow. And the rest of the program happily runs on - it does not get
blocked.

In general, when you're running with THREADSAFE=Y, then Microwindows
executes a mutex before entering the otherwise potentially nonthreadsafe
code.  It's likely that one of your other threads is already in the
mutex when you execute the GrLowerWindow, and the new thread
hangs.

GrLowerWindow doesn't require a response from the server, so its
implementation normally just writes a code down the server socket.
However, the flush() to the socket only happens normally when a
response is required, or GrGetNextEvent is called.  Of course,
if two threads are currently writing the socket at the same time,
with some kernels the writes can get intermixed.  You might
try running without the THREADSAFE=Y option, otherwise
you unfortunately might have to synchronize your threads and have
only one thread make GrXXX calls.

Regards,

Greg


[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.