[Xcb] Feature Request: Function "xcb_test_for_event"

[Christian Heller]

Hi Bart,

> As Josh suggests, if you want to wait on multiple things at once, spawn a
> blocking thread per thing, and demux the result using the usual thread
> mechanisms. Pipes are probably overkill here: just use a locked queue. If
> you use a semaphore for locking the queue, you can block until something is
> in it conveniently.

there has been a lot of scientific debate about pros & cons of threads:
http://www.stanford.edu/~ouster/cgi-bin/papers/threads.pdf

which I do not want to take part in. For the cyboi interpreter,
I have decided to let the main thread do everything and use threads
for detection of data on the various communication channels only.

Locking the queue is actually a good idea.

1 However, the cyboi queue is only allowed to store data in a format
called "part", in order to be able to process data in a uniform way.
Therefore, the queue cannot take terminal data, x window system mouse
click and other things in a mixed way.

2 The necessity to wrap each event as "part" would force the various
"detection" threads to allocate a "part" for each event arriving.
This would lead to conflicts with the main thread.
The reason is that there is only one global "knowledge tree" keeping
ALL parts, also those representing an event. While some "detection"
thread manipulates a part, the main thread might access it as well.
I therefore just set a flag (using mutex) informing the main thread.

(Side remark: The cybol language uses the same xml syntax for space+time,
i.e. for describing a gui or address or electronic health record = state
and for describing a function or workflow or algorithm = logic over time.
Each logic part may be put as event to the queue.)

Christian

-- 
Reform our monetary system! Money is a public infrastructure.
Use flowing money with demurrage, complementary, community currencies!
http://www.humane-wirtschaft.de/beitraege/in-english/