[Xcb] Feature Request: Function "xcb_test_for_event"

[Christian Heller]

Hi Josh,

thanks for replying.

> Detecting events by polling periodically is highly inefficient; you
> really want some mechanism that will block until you recieve an event.
> So, first of all, I would not recommend adding an "xcb_test_for_event"
> function, because I don't see any way you could use it without polling.
[..]

you are right in that this kind of "busy waiting" (loop + sleep) that
I use is not very efficient. A blocking function would be much nicer.
However, I cannot use "xcb_wait_for_event" for reasons I explain following.

CYBOI tries to offer all possible communication channels transparently.
Application programmers should write their programme in CYBOL (XML) only.
All they have to do is write "send" or "receive" and give a "channel",
e.g.: inline text, file, terminal, serial_port, x_window_system, socket.
The rest is done by CYBOI internally.

CYBOI starts up, runs the usual event loop, handles events, shuts down.
This all in the main thread. Additional threads may be started ONLY for
detection, but NOT for reception or sending of data. This is to avoid
memory conflicts. Just a design decision that I wouldn't like to change.

Now, the "detection" threads somehow have to inform the "main" thread,
if data arrived on some channel. This is done via simple "int" variables,
something like an internal interrupt request (irq) flag. So I have to
use "busy waiting" at least on this point of the code.

Detection of the different channels is done like this:
- terminal: fgetwc + ungetwc
- serial_port: fgetc + ungetc
- socket: accept
- x_window_system: int n = XEventsQueued(d, QueuedAfterReading);

The terminal and serial_port functions are blocking, which is nice.
But I have to write back the received character with "ungetc". Why?
Because the receiving of data shall be done in the main thread only.
For the socket, all that is to be stored is a single integer number
representing the client socket, which is not that problematic.

Concerning "x_window_system": If using "xcb_wait_for_event", I am
forced to store the event received in the "detection" thread.
Then, the main thread gets informed that events are available.
In the main thread, I would have to use that stored first event
and receive further events using "xcb_poll_for_event", because the
main thread is not allowed to block, since further communication
might occur on other channels.

I'd prefer not to store any event in the "detection" thread.
It would be nicer to have a function just notifying me if there are
events available (a simple int flag returned, no event).
Ideally -- you are right -- that function would be a BLOCKING one!
So, if you could make "xcb_test_for_event" blocking, even better.

> For your use case, you really want a blocking function like
> xcb_wait_for_event, but without actually returning the event;
> it should block until at least one event exists to return.

Yes, exactly. This is what I need. Thanks for clarifying.

> That still seems suboptimal for the purposes of most event loops (which
[..]

I am aware of the disadvantages of "busy waiting". But this is the
price of flexibility in CYBOI. All communication channels shall be
used easily. In effect, CYBOI with its irq flags (between "detection"
threads and "main" thread) tries to do what is an operating system's task.

I am constantly looking for optimisations and am thankful for ideas.

Christian

--
Reform our monetary system!
Use flowing money with demurrage, complementary, community currencies!
Central banks like Fed are private. Let the state issue money!
http://www.humane-wirtschaft.de/beitraege/in-english/