nanogui: Corrupted Packet Nano-X


Previous by date: 14 Sep 2007 13:16:03 +0100 Re: Japanese fonts with uClinux, Greg Haerr
Next by date: 14 Sep 2007 13:16:03 +0100 Re: Corrupted Packet Nano-X, Greg Haerr
Previous in thread: 14 Sep 2007 13:16:03 +0100 Re: Corrupted Packet Nano-X, Greg Haerr
Next in thread: 14 Sep 2007 13:16:03 +0100 Re: Corrupted Packet Nano-X, Greg Haerr

Subject: Re: [nanogui] Corrupted Packet Nano-X
From: ####@####.####
Date: 14 Sep 2007 13:16:03 +0100
Message-Id: <20070914071557.bfxfahk7go8sc0w4@localhost>

Hi Greg,

> So maybe the multithreading is the problem?
>
>
> I should have asked this in the beginning, its definitely the problem.
> Despite having THREADSAFE=Y, if more than one makes
> a request with a non-void GrXXX function (that is, one that
> requires a response from the server), then the client/server
> interaction on the single pipe to the application gets out of
> sync, and the "corrupted packet" message is generated.
> This is because two threads have attempted to read or
> write the pipe at the same time, and junk gets written
> in the middle of a packet.

Am I missing something?
How can two threads read or write the pipe at the same time? All GrXXX  
functions are protected by the nxGlobalLock mutex, which would mean,  
that only one thread at the time can access the pipe. The one holding  
the lock.

>
> The THREADSAFE option puts mutex's to protect
> against a task switch between two writers, but
> can't protect against a thread trying to read a response
> while another, usually the main thread, is in GrGetNextEvent.

I believe that only with my patch, which unlocks before select and  
locks after select in _GrGetNextEventTimeout you can have a situation  
like the one you describe.

Besides that if you apply my patch and call non void functions from  
different threads you can have a deadlock because the read inside  
ReadBlock is blocking. (You can make it non blocking, which might lead  
to starvation;)
The following is the scenario:
In GrGetNextEvent unlock and call select
No event is coming

Another thread can run and since we are unlocked do stuff, which leads  
to a call to read.
Since now this GrXXX took the lock and GrGetNextEvent would need the  
lock to process the event, we are deadlocked.

With LINK_APP_INTO_SERVER everything seems to work, which looks like  
there is something wrong with the client server communication.

Do you think it would help to have different read and write file descriptors?

Regards,

Robert

Previous by date: 14 Sep 2007 13:16:03 +0100 Re: Japanese fonts with uClinux, Greg Haerr
Next by date: 14 Sep 2007 13:16:03 +0100 Re: Corrupted Packet Nano-X, Greg Haerr
Previous in thread: 14 Sep 2007 13:16:03 +0100 Re: Corrupted Packet Nano-X, Greg Haerr
Next in thread: 14 Sep 2007 13:16:03 +0100 Re: Corrupted Packet Nano-X, Greg Haerr


Powered by ezmlm-browse 0.20.