<div dir="ltr"><div style>I believe this is what you are looking for:</div><div><br></div><div>int <span class="" style="white-space:pre"> </span>xcb_get_file_descriptor (xcb_connection_t *c)</div><div> <span class="" style="white-space:pre"> </span>Access the file descriptor of the connection. ]</div> <div><br></div><div style>Awesome WM currently uses this with glib, and in the past it used it with libev.</div><div style>bspwm uses this to do something similar to what you are doing. <a href="https://github.com/baskerville/bspwm">https://github.com/baskerville/bspwm</a> </div> </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 5:22 PM, Josh Triplett <span dir="ltr"><<a href="mailto:josh@joshtriplett.org" target="_blank">josh@joshtriplett.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, Apr 06, 2013 at 01:46:14PM +0200, Christian Heller wrote:<br> > Hi Josh,<br> ><br> > thanks for replying.<br> ><br> > > Detecting events by polling periodically is highly inefficient; you<br> > > really want some mechanism that will block until you recieve an event.<br> > > So, first of all, I would not recommend adding an "xcb_test_for_event"<br> > > function, because I don't see any way you could use it without polling.<br> > [..]<br> ><br> > you are right in that this kind of "busy waiting" (loop + sleep) that<br> > I use is not very efficient. A blocking function would be much nicer.<br> > However, I cannot use "xcb_wait_for_event" for reasons I explain following.<br> ><br> > CYBOI tries to offer all possible communication channels transparently.<br> > Application programmers should write their programme in CYBOL (XML) only.<br> > All they have to do is write "send" or "receive" and give a "channel",<br> > e.g.: inline text, file, terminal, serial_port, x_window_system, socket.<br> > The rest is done by CYBOI internally.<br> ><br> > CYBOI starts up, runs the usual event loop, handles events, shuts down.<br> > This all in the main thread. Additional threads may be started ONLY for<br> > detection, but NOT for reception or sending of data. This is to avoid<br> > memory conflicts. Just a design decision that I wouldn't like to change.<br> ><br> > Now, the "detection" threads somehow have to inform the "main" thread,<br> > if data arrived on some channel. This is done via simple "int" variables,<br> > something like an internal interrupt request (irq) flag. So I have to<br> > use "busy waiting" at least on this point of the code.<br> ><br> > Detection of the different channels is done like this:<br> > - terminal: fgetwc + ungetwc<br> > - serial_port: fgetc + ungetc<br> > - socket: accept<br> > - x_window_system: int n = XEventsQueued(d, QueuedAfterReading);<br> ><br> > The terminal and serial_port functions are blocking, which is nice.<br> > But I have to write back the received character with "ungetc". Why?<br> > Because the receiving of data shall be done in the main thread only.<br> > For the socket, all that is to be stored is a single integer number<br> > representing the client socket, which is not that problematic.<br> <br> </div></div>You don't need to get a character to block on a terminal or serial port.<br> You should just select() or poll() or epoll() or similar on the file<br> descriptor. Likewise with sockets, and in fact you can watch many file<br> descriptors with a single select/poll/epoll/etc. That'll eliminate the<br> unget.<br> <br> Ideally, you should use one of those calls on your main thread rather<br> than flag variables. If you have to wait on something for which you<br> don't have a file descriptor, you could always spin off a thread and<br> have it write a byte to a pipe when ready, then add the read end of the<br> pipe as another file descriptor to block on.<br> <br> You might also look at timerfd, signalfd, and similar calls; those make<br> it possible to include even more things in your select/poll/epoll.<br> <br> Depending on your target platforms, you may also find the portable<br> libevent or libev wrappers useful, rather than calling epoll or similar<br> directly.<br> <div class="im"><br> > Concerning "x_window_system": If using "xcb_wait_for_event", I am<br> > forced to store the event received in the "detection" thread.<br> > Then, the main thread gets informed that events are available.<br> > In the main thread, I would have to use that stored first event<br> > and receive further events using "xcb_poll_for_event", because the<br> > main thread is not allowed to block, since further communication<br> > might occur on other channels.<br> ><br> > I'd prefer not to store any event in the "detection" thread.<br> > It would be nicer to have a function just notifying me if there are<br> > events available (a simple int flag returned, no event).<br> > Ideally -- you are right -- that function would be a BLOCKING one!<br> > So, if you could make "xcb_test_for_event" blocking, even better.<br> ><br> > > For your use case, you really want a blocking function like<br> > > xcb_wait_for_event, but without actually returning the event;<br> > > it should block until at least one event exists to return.<br> ><br> > Yes, exactly. This is what I need. Thanks for clarifying.<br> <br> </div>OK, glad to hear that blocking would work for you.<br> <br> Ideally I'd still love to have some way for XCB to just supply a file<br> descriptor you can block on, but I don't know if the structure of the X<br> protocol would reasonably allow that. Failing that, an<br> xcb_block_until_event or xcb_wait_for_event_noret or similar call seems<br> vaguely reasonable.<br> <div class="im"><br> > > That still seems suboptimal for the purposes of most event loops (which<br> > [..]<br> ><br> > I am aware of the disadvantages of "busy waiting". But this is the<br> > price of flexibility in CYBOI. All communication channels shall be<br> > used easily. In effect, CYBOI with its irq flags (between "detection"<br> > threads and "main" thread) tries to do what is an operating system's task.<br> ><br> > I am constantly looking for optimisations and am thankful for ideas.<br> <br> </div>You should definitely look into the select/poll/epoll family of<br> syscalls.<br> <span class="HOEnZb"><font color="#888888"><br> - Josh Triplett<br> </font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br> Xcb mailing list<br> <a href="mailto:Xcb@lists.freedesktop.org">Xcb@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/xcb" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xcb</a><br> </div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Praising my Savior all the day long,<div>Micah Nordland</div> </div>