Bug 808 - Xt: XtAppAddInput additional input sometimes ignored in multi-threaded application
Summary: Xt: XtAppAddInput additional input sometimes ignored in multi-threaded applic...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xt (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2004-06-29 06:24 UTC by Andreas Luik
Modified: 2007-04-07 14:44 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
mttest test program (gzipped tar file) (1.80 KB, application/octet-stream)
2004-06-29 06:29 UTC, Andreas Luik
no flags Details
context diff to lib/Xt/NextEvent.c, either workaround of fix (564 bytes, patch)
2004-06-29 06:34 UTC, Andreas Luik
no flags Details | Splinter Review

Description Andreas Luik 2004-06-29 06:24:24 UTC
The X Toolkit does not call the callback function registered with
XtAppAddInput when there is some input pending on the registered file
descriptor, unless an X event has recently been processed.  This can
easily been reproduced with the attached test program.

The program consists of three threads:

- main thread: initialization, makes a pipe, registers the pipe[0] fd
as additional input, creates two other threads and runs the X Toolkit
main loop (XtAppNextEvent and XtDispatchEvent).

- WorkThread: endless loop, which calls XQueryTree and then sleeps for
three seconds.

- SignalWaiterThread: handles SIGINT signal using sigwait(), and
writes to pipe[1] when a signal has arrived.

When SIGINT is catched, the input callback for pipe[0] should be
called, but most of the time, it is not.  You can enforce the callback
to be called by generating an X event, e.g. by using the command
"xmodmap -e 'pointer = default'".
Comment 1 Andreas Luik 2004-06-29 06:29:14 UTC
Created attachment 428 [details]
mttest test program (gzipped tar file)

How to use the test program:

Compile the attached mttest.c program using the Imakefile.
Run it with "./mttest".
Press the INTR character several times.  Observe that the signal
handler is called, but the additional input is not recognized.	The
output is:

pascal:/(162)> ./mttest 
pipe 4
Work is active ...
./mttest: [signal waiter]: signal 2
./mttest: [signal waiter]: signal 2
./mttest: [signal waiter]: signal 2
./mttest: [signal waiter]: signal 2
...

Whereas it should be:

pascal:/(162)> ./mttest 
pipe 4
Work is active ...
./mttest: [signal waiter]: signal 2
ReadControlConnectionCB
./mttest: received SIGN 2

./mttest: [signal waiter]: signal 2
ReadControlConnectionCB
./mttest: received SIGN 2

./mttest: [signal waiter]: signal 2
ReadControlConnectionCB
./mttest: received SIGN 2

...
Comment 2 Andreas Luik 2004-06-29 06:34:50 UTC
Created attachment 429 [details] [review]
context diff to lib/Xt/NextEvent.c, either workaround of fix

With this patch applied to NextEvent.c, the bug seems to not occur.  Might
have a small performance penalty, because the fdlist is now rebuild more
often.	On the other hand, I think this might be required, because
select() modifies the fd_sets ...
Comment 3 Roland Mainz 2004-07-19 16:28:13 UTC
Comment on attachment 429 [details] [review]
context diff to lib/Xt/NextEvent.c, either workaround of fix

alan/egbert:
Do you know anyone who is able to review the patch ?
Comment 4 Erik Andren 2006-04-25 07:25:57 UTC
Ping!
Comment 5 Daniel Stone 2007-02-27 01:23:40 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 6 Daniel Stone 2007-04-07 14:44:06 UTC
committed, not quite three years later.  thanks for the patch!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.