[Xcb] [PATCH 4/8] Add xcb_send_fd API

[Keith Packard]

Uli Schlachter <psychon at 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

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20131107/92bcebc9/attachment.pgp>