nanogui: Corrupted Packet Nano-X
Subject:
Re: [nanogui] Corrupted Packet Nano-X
From:
"Greg Haerr" ####@####.####
Date:
14 Sep 2007 18:20:45 +0100
Message-Id: <160a01c7f6f3$91439640$6401a8c0@winXP>
> 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.
That's correct, but its more complicated than that. The corrupted
packet has to do with a sync issue that arises when a non-void
GrXXX call reads the pipe to get its return data, but gets an
out-of-sync event from the server instead.
The "threading" issue is probably more of a client/server
synchronisation issue, that the current (only) nano-X
protocol requires client and server stay completely
in-sync. There was never any design in the protocol
to allow for asynchronous event delivery etc that requires
lots more tricky code and queuing on both client and
server sides.
>
> 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.
I hadn't known you're running your patched code for threading
and now getting corrupted packet errors. I can't comment on
that without heavily studying your patch.
> With LINK_APP_INTO_SERVER everything seems to work, which looks like
there is something wrong with the client server communication.
Agreed.
> Do you think it would help to have different read and write file
descriptors?
No
Regards,
Greg
