When events are queued, the associated proxy objects (target proxy and
potentially closure argument proxies) are verified being valid. However,
as any event may destroy some proxy object, validity needs to be
verified again before dispatching. Before this change this was done by
again looking up the object via the display object map, but that did not
work because a delete_id event could be dispatched out-of-order if it
was queued in another queue, causing the object map to either have a new
proxy object with the same id or none at all, had it been destroyed in
an earlier event in the queue.
Instead, make wl_proxy reference counted and increase the reference
counter of every object associated with an event when it is queued. In
wl_proxy_destroy() set a flag saying the proxy has been destroyed by the
application and only free the proxy if the reference counter reaches
zero after decreasing it.
Before dispatching, verify that a proxy object still is valid by
checking that the flag set in wl_proxy_destroy() has not been set. When
dequeuing the event, all associated proxy objects are dereferenced and
free:ed if the reference counter reaches zero. As proxy reference counter
is initiated to 1, when dispatching an event it can never reach zero
without having the destroyed flag set.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Exporting unprefixed symbols is a pretty bad idea so don't do that.
Instea of redefining it WL_ARRAY_LENGTH, we just move the define to
our private header. The scanner generates code that uses ARRAY_LENGTH,
but we can just make it count the number elements and emit an integer
constant instead.
On the client side where we queue up multiple events before dispatching, we
need to look up the receiving proxy and argument proxies immediately before
calling the handler. Between queueing up multiple events and eventually
invoking the handler, previous handlers may have destroyed some of the
proxies.
The update callback for the file descriptors was always a bit awkward and
un-intuitive. The idea was that whenever the protocol code needed to
write data to the fd it would call the 'update' function. This function
would adjust the mainloop so that it polls for POLLOUT on the fd so we
can eventually flush the data to the socket.
The problem is that in multi-threaded applications, any thread can issue
a request, which writes data to the output buffer and thus triggers the
update callback. Thus, we'll be calling out with the display mutex
held and may call from any thread.
The solution is to eliminate the udpate callback and just require that
the application or server flushes all connection buffers before blocking.
This turns out to be a simpler API, although we now require clients to
deal with EAGAIN and non-blocking writes. It also saves a few syscalls,
since the socket will be writable most of the time and most writes will
complete, so we avoid changing epoll to poll for POLLOUT, then write and
then change it back for each write.
Expose these to other files using wayland-private.h, so wayland-client.c
can walk NULLables properly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The core libwayland libraries should not handle logging, only passing
the error messages to subscribed functions.
An application linked to libwayland-server or libwayland-client
will be able to set own functions (one per library) to handle error
messages.
Change in this series: make the wl_log return int, because
of compatibility with printf. It will return the number of bytes logged.
In case the client isn't responding, this will block the compositor.
Instead we flush with MSG_DONTWAIT, which lets us fill up the kernel buffer
as much as we can (after not returning EPOLLOUT anymore it still can take
80k more), and then disconnect the client if we get EAGAIN.
We set aside a range of the object ID space for use by the server. This
allows the server to bind an object to an ID for a client and pass that
object to the client. The client can use the object immediately and the
server can emit events to the object immdiately.
