[vox-tech] Xlib event loop

[R. Douglas Barbieri]

--NDin8bjvE/0mNLFQ
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 19, 2003 at 01:51:10PM +1100, Julie Russell wrote:
> Hi there,
>=20
> What I am doing is I am calling XPutImage from a threaded output class, a=
nd
> I want to keep it there for 20 seconds, then grab the next image, etc.
> However, these images can be interrupted by a keypress event, so while th=
ey
> are showing, I need to still get events from the event loop. I have my ev=
ent
> handler as a non-threaded singleton class that can just be called when an
> event needs to be sent. The images sit on a child window, and the event
> handler listens to the parent. Should sleep on a child window of a detach=
ed
> thread class stop the event loop on the parent? Could it be from what you=
're
> saying that the XImage output is blocking the XEvent? If the sleep process
> if blocking it, then I would have to determine another way to count 20
> seconds for the blit.

I would guess that, yes, sleeping a thread which has an event loop could
block the whole application. Are you just calling sleep(20*blah) to
pause the thread?  If so, you may want to consider creating a
pthread-style mutex, then using pthread_mutex_timedwait().  Make the
timeout something small like 1 second or less. The loop could look like
this:

do
{
	struct timeval  now;
	struct timespec timeout;
	gettimeofday( &now, NULL );
	timeout.tv_sec  =3D now.tv_sec  + 1;
	timeout.tv_nsec =3D now.tv_usec * 1000;

	... Pump the event queue ...
}
while( pthread_mutex_timedwait( &mutex_handle, &timeout );

The "timedwait" pthread function will drop out once every one second
while the mutex is locked, allowing your application to keep the UI
active and events processing.

Check out VncSelector (http://www.dooglio.net/VncSelector, version 1.1)
for a code sample. I am using a pthread conditional instead of a mutex,
but it works out the same. When the conditional's signal is raised, that
terminates the runner thread. Otherwise it stays running.

I needed to be able to pop up a dialog box which says "Please Wait", but
when I tried fork, and waitpid() in the parent process, my application
would completely freeze and the wait dialog would look transparent.
Moving the fork() and waitpid() calls to a runner thread allowed me to
post the dialog correctly, then block for the child process to finish.
The interesting thing to note that while I'm doing a waitpid() in the
runner thread, the entire application blocks.

Hope this helps!

>=20
> Thanks,
> Julie.
>=20
> > -----Original Message-----
> > From: vox-tech-admin@lists.lugod.org
> > [mailto:vox-tech-admin@lists.lugod.org]On Behalf Of R. Douglas Barbieri
> > Sent: Friday, 19 December 2003 1:14 PM
> > To: vox-tech@lists.lugod.org
> > Subject: Re: [vox-tech] Xlib event loop
> >
> >
> > On Fri, Dec 19, 2003 at 11:47:00AM +1100, Julie Russell wrote:
> > > Hi Everyone,
> > >
> > > I am programming in c++ and xlib using common c++ threads. I
> > want to sleep a
> > > thread (which I have initiated as detached). During that
> > process I want to
> > > recieve events from the xlib event loop and if triggered, interrupt t=
he
> > > sleeping thread, or if not interrupted, have the thread wake up
> > on it's own
> > > after 20 seconds. The problem is, while that thread is asleep, for so=
me
> > > reason, my event loop appears to be blocked. How can I sleep a thread=
 so
> > > that the loop doesn't block and then interrupt it cleanly. Why
> > does the xlib
> > > event loop appear to be blocked during this process.
> >
> > I can think of how I would do this in Win32 There is a API function
> > called PeekMessage() which "peeks" at the pending message waiting but
> > does not block. I would use that, but for sleeping the thread, use
> > WaitOnMultipleObjects().
> >
> > So, if there is a similar function for xlib which allows just a "peek,"
> > I would use it instead so that the thread doesn't block there. Then
> > use the pthread_cond_timeout() function to sleep. A signal to the
> > conditional object terminates the thread loop then.
> >
> > I read somewhere that X likes all X-related calls to happen in just one
> > thread. It could be that when you read the next event, it blocks because
> > there is other X activity in the other thread? Just a guess, really.
> >
> > >
> > > Thanks in advance,
> > > Julie.
> > >
> > >
> > >
> > > _______________________________________________
> > > vox-tech mailing list
> > > vox-tech@lists.lugod.org
> > > http://lists.lugod.org/mailman/listinfo/vox-tech
> >
> > --
> > R. Douglas Barbieri
> > doug@dooglio.net
> > http://www.dooglio.net
> >
> > GPG Fingerprint : FE6A 6A57 2B95 7594 E534  BFEE 45F1 9E5E F30A 8A27
> > MIT.edu recv-key: C55B91D4
> > GPG Public key  : http://www.dooglio.net/dooglio.asc
> >
>=20
>=20
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

--=20
R. Douglas Barbieri
doug@dooglio.net
http://www.dooglio.net

GPG Fingerprint : FE6A 6A57 2B95 7594 E534  BFEE 45F1 9E5E F30A 8A27
MIT.edu recv-key: C55B91D4
GPG Public key  : http://www.dooglio.net/dooglio.asc

--NDin8bjvE/0mNLFQ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iQCVAwUBP+KPuEXxnl7zCoonAQJXsAP/clAXgjSHYTtgIxlKC2Gzn1/cUFiV+XAt
r1WpNAcV8GEC7l4SSuXeRN6zoqLpL1CnyUqO/qceS+wuOrV52fmojrBmAu0/Zpk5
DYPQ0hx2EwaHLPnNg4k81rJsyC7GC8PtA/lhbaMW0ftweGz7ah4PIuPqqyxOhf9M
P/Q06TdRq1o=
=IZ0G
-----END PGP SIGNATURE-----

--NDin8bjvE/0mNLFQ--