nanogui: Difficulty Using GrInjectKeyboardEvent()


Previous by date: 28 Aug 2008 17:29:01 -0000 Re: Difficulty Using GrInjectKeyboardEvent(), Gil Glass
Next by date: 28 Aug 2008 17:29:01 -0000 Re: Difficulty Using GrInjectKeyboardEvent(), Kees Schoenmakers
Previous in thread: 28 Aug 2008 17:29:01 -0000 Re: Difficulty Using GrInjectKeyboardEvent(), Gil Glass
Next in thread: 28 Aug 2008 17:29:01 -0000 Re: Difficulty Using GrInjectKeyboardEvent(), Kees Schoenmakers

Subject: Re: [nanogui] Difficulty Using GrInjectKeyboardEvent()
From: "Greg Haerr" ####@####.####
Date: 28 Aug 2008 17:29:01 -0000
Message-Id: <04bf01c90933$6db43b00$0300a8c0@RDP>

> 3.  send it on to clients that are selecting on the event.
> Using GrInjectKeyboardEvent() only does the first two things.

Of course...  the client thread is hanging on a real select() call
in srvmain.c::GsSelect(), and doesn't unblock just because
the other thread posted an event into a memory location.

We'll need some IPC method of having the calling thread
unblock the waiting thread when the event is posted.

The reason I think this works in the non LINK_APP_INTO_SERVER
case is because the server checks for events in application
queues and sends a byte across the pipe for any applications
which are currently blocked in GrGetNextEvent, which 
wakes them up by allowing them to read.

In your case, one simple approach would be to never
hang in GrGetNextEvent very long, that is, set a small
interval timeout, which will cause the thread to at
least loop once in GsSelect every so many milliseconds.

Regards,

Greg

Previous by date: 28 Aug 2008 17:29:01 -0000 Re: Difficulty Using GrInjectKeyboardEvent(), Gil Glass
Next by date: 28 Aug 2008 17:29:01 -0000 Re: Difficulty Using GrInjectKeyboardEvent(), Kees Schoenmakers
Previous in thread: 28 Aug 2008 17:29:01 -0000 Re: Difficulty Using GrInjectKeyboardEvent(), Gil Glass
Next in thread: 28 Aug 2008 17:29:01 -0000 Re: Difficulty Using GrInjectKeyboardEvent(), Kees Schoenmakers


Powered by ezmlm-browse 0.20.