On 7 November 2013 13:14, Keith Packard <kei...@keithp.com> wrote: > Uli Schlachter <psyc...@znc.in> writes: > >> The above seems to be an unrelated change. If this is needed due to some >> xcb-private header, then that header needs to be fixed. Otherwise this seems >> unneeded (for this patch). > > Yup, I figured out how to make it compile without the network header > edits; just needed to add sys/socket.h to xcbint.h and all is well. > >> This indents with tabs. I know that there is no coding style documented >> anywhere, but "most" of libxcb only uses spaces. > > I'll fix that; xcb is 'outside' my xorg environment, and so doesn't > inherit the usual xorg editor settings. > >>> +void >>> +xcb_send_fd(xcb_connection_t *c, int fd) >>> +{ >>> +#if HAVE_SENDMSG >> >> if (c->has_error) >> return; >> >> This is needed before the pthread_mutex_lock(), because if >> xcb_connect_to_display() fails, it returns a pointer to an integer. The >> has_error 'field' is the only thing that might be accessed for such a >> connection >> object. > > Ok, you just want an additional check for errors in case the display > object doesn't even have the iolock initialized. Makes sense. > >> >>> + pthread_mutex_lock(&c->iolock); >>> + while (c->out.out_fd.nfd == XCB_MAX_PASS_FD) { >>> + _xcb_out_flush_to(c, c->out.request); >>> + if (c->has_error) >>> + break; >>> + } >>> + if (!c->has_error) >>> + c->out.out_fd.fd[c->out.out_fd.nfd++] = fd; >>> + pthread_mutex_unlock(&c->iolock); >>> +#endif >>> +} >> >> So, xcb_send_fd() hands FDs to libxcb which will all be included in the next >> flush. The idea is that the user of the library calls (through the >> automatically >> generated protocol functions) xcb_send_fd() and then >> xcb_send_request(). Correct? > > Yes. > >> However, what happens if the connection is flushed between the xcb_send_fd() >> and >> the xcb_send_request() calls, because another thread "interferes"? This can >> also >> happen with a single thread: xcb_send_request() could have to insert sync >> requests (GetInputFocus) because of sequence number 0 or sequence number >> wraps. >> This could cause the output buffer to go full before the "real" >> request is inserted. > > It doesn't matter as long as the FDs arrive before the full request in > the X server. Given how FD passing works, there's no direct association > between the FDs received and the requests within the X server > anyways. > >> I guess that the server expects the FDs to be sent with the request that they >> are meant to (otherwise I could feed the server lots of FDs which it would >> have >> to keep around forever). So this function doesn't really work, does >> it? > > That's the X server's problem, and it gets to deal with clients that > don't play nice. > > I cannot get version 1.9.1 to build at all, which makes the prospects > of releasing something on top of that pretty uncertain... > > Traceback (most recent call last): > File "./c_client.py", line 2925, in <module> > module.generate() > File "/local/xorg/lib/python2.7/site-packages/xcbgen/state.py", line 103, > in generate > item.out(name) > File "./c_client.py", line 2788, in c_request > _c_type_setup(self, name, ('request',)) > File "./c_client.py", line 338, in _c_type_setup > _c_type_setup(field.type, field.field_type, ()) > File "./c_client.py", line 413, in _c_type_setup > _c_serialize('serialize', self) > File "./c_client.py", line 1171, in _c_serialize > count = _c_serialize_helper(context, self, code_lines, temp_vars, > prefix=prefix) > File "./c_client.py", line 1045, in _c_serialize_helper > space, prefix) > File "./c_client.py", line 690, in _c_serialize_helper_switch > bitcase_expr = _c_accessor_get_expr(b.type.expr, None) > File "./c_client.py", line 1417, in _c_accessor_get_expr > lenexp = _c_accessor_get_length(expr, field_mapping) > File "./c_client.py", line 1394, in _c_accessor_get_length > lenfield_name = expr.lenfield_name > AttributeError: 'list' object has no attribute 'lenfield_name' > make[1]: *** [sync.c] Error 1
Sounds like this commit is missing: c_client.py: Handle multiple expr. in a bitcase http://cgit.freedesktop.org/xcb/libxcb/commit/?id=e602b65 which is the counterpart for: xcbgen: Handle multiple <enumref> in a <bitcase> http://cgit.freedesktop.org/xcb/proto/commit/?id=a9a892e > > -- > keith.pack...@intel.com > > _______________________________________________ > Xcb mailing list > x...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xcb _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel