2008-12-02 15:15:01 -05:00
|
|
|
/*
|
2012-10-04 16:54:22 -04:00
|
|
|
* Copyright © 2008-2012 Kristian Høgsberg
|
|
|
|
|
* Copyright © 2010-2012 Intel Corporation
|
2008-12-02 15:15:01 -05:00
|
|
|
*
|
|
|
|
|
* Permission to use, copy, modify, distribute, and sell this software and its
|
|
|
|
|
* documentation for any purpose is hereby granted without fee, provided that
|
|
|
|
|
* the above copyright notice appear in all copies and that both that copyright
|
|
|
|
|
* notice and this permission notice appear in supporting documentation, and
|
|
|
|
|
* that the name of the copyright holders not be used in advertising or
|
|
|
|
|
* publicity pertaining to distribution of the software without specific,
|
|
|
|
|
* written prior permission. The copyright holders make no representations
|
|
|
|
|
* about the suitability of this software for any purpose. It is provided "as
|
|
|
|
|
* is" without express or implied warranty.
|
|
|
|
|
*
|
|
|
|
|
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
|
|
|
|
|
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
|
|
|
|
|
* EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
|
|
|
|
|
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
|
|
|
|
|
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
|
|
|
|
|
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
|
|
|
|
|
* OF THIS SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
2008-10-07 10:10:36 -04:00
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <stdint.h>
|
|
|
|
|
#include <stddef.h>
|
|
|
|
|
#include <stdio.h>
|
2011-07-14 18:56:40 +03:00
|
|
|
#include <stdbool.h>
|
2008-10-07 10:10:36 -04:00
|
|
|
#include <errno.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
#include <unistd.h>
|
|
|
|
|
#include <sys/socket.h>
|
|
|
|
|
#include <sys/un.h>
|
|
|
|
|
#include <ctype.h>
|
2008-12-21 21:50:23 -05:00
|
|
|
#include <assert.h>
|
2011-04-11 09:24:11 -04:00
|
|
|
#include <fcntl.h>
|
2008-10-07 10:10:36 -04:00
|
|
|
#include <sys/poll.h>
|
2012-10-04 17:42:49 -04:00
|
|
|
#include <pthread.h>
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2008-11-23 23:41:08 -05:00
|
|
|
#include "wayland-util.h"
|
2012-03-21 11:11:26 +02:00
|
|
|
#include "wayland-os.h"
|
2008-10-08 13:32:07 -04:00
|
|
|
#include "wayland-client.h"
|
2011-11-18 13:46:56 -05:00
|
|
|
#include "wayland-private.h"
|
2008-10-08 13:32:07 -04:00
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
|
|
|
|
|
/** \cond */
|
|
|
|
|
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
enum wl_proxy_flag {
|
|
|
|
|
WL_PROXY_FLAG_ID_DELETED = (1 << 0),
|
|
|
|
|
WL_PROXY_FLAG_DESTROYED = (1 << 1)
|
|
|
|
|
};
|
|
|
|
|
|
2008-12-30 11:03:33 -05:00
|
|
|
struct wl_proxy {
|
2010-12-01 17:07:41 -05:00
|
|
|
struct wl_object object;
|
2008-12-30 11:03:33 -05:00
|
|
|
struct wl_display *display;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
struct wl_event_queue *queue;
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
uint32_t flags;
|
|
|
|
|
int refcount;
|
2009-09-18 09:49:21 -04:00
|
|
|
void *user_data;
|
2008-10-07 10:10:36 -04:00
|
|
|
};
|
|
|
|
|
|
2011-04-14 10:38:44 -04:00
|
|
|
struct wl_global {
|
|
|
|
|
uint32_t id;
|
|
|
|
|
char *interface;
|
|
|
|
|
uint32_t version;
|
|
|
|
|
struct wl_list link;
|
|
|
|
|
};
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
struct wl_event_queue {
|
2012-10-11 23:37:51 +02:00
|
|
|
struct wl_list link;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
struct wl_list event_list;
|
2012-10-11 23:37:51 +02:00
|
|
|
struct wl_display *display;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
pthread_cond_t cond;
|
|
|
|
|
};
|
|
|
|
|
|
2008-12-30 11:03:33 -05:00
|
|
|
struct wl_display {
|
|
|
|
|
struct wl_proxy proxy;
|
|
|
|
|
struct wl_connection *connection;
|
2012-10-11 23:37:42 +02:00
|
|
|
int last_error;
|
2008-12-30 11:03:33 -05:00
|
|
|
int fd;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
pthread_t display_thread;
|
2011-08-19 22:50:53 -04:00
|
|
|
struct wl_map objects;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
struct wl_event_queue queue;
|
2012-10-11 23:37:51 +02:00
|
|
|
struct wl_list event_queue_list;
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_t mutex;
|
2008-12-30 11:03:33 -05:00
|
|
|
};
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** \endcond */
|
|
|
|
|
|
2011-02-10 12:27:35 -05:00
|
|
|
static int wl_debug = 0;
|
|
|
|
|
|
2012-10-11 23:37:53 +02:00
|
|
|
static void
|
|
|
|
|
display_fatal_error(struct wl_display *display, int error)
|
|
|
|
|
{
|
|
|
|
|
struct wl_event_queue *iter;
|
|
|
|
|
|
|
|
|
|
if (display->last_error)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (!error)
|
|
|
|
|
error = 1;
|
|
|
|
|
|
|
|
|
|
display->last_error = error;
|
|
|
|
|
close(display->fd);
|
|
|
|
|
display->fd = -1;
|
|
|
|
|
|
|
|
|
|
wl_list_for_each(iter, &display->event_queue_list, link)
|
|
|
|
|
pthread_cond_broadcast(&iter->cond);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wl_display_fatal_error(struct wl_display *display, int error)
|
|
|
|
|
{
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
|
|
|
|
display_fatal_error(display, error);
|
|
|
|
|
pthread_mutex_unlock(&display->mutex);
|
|
|
|
|
}
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
static void
|
2012-10-11 23:37:51 +02:00
|
|
|
wl_event_queue_init(struct wl_event_queue *queue, struct wl_display *display)
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
{
|
|
|
|
|
wl_list_init(&queue->event_list);
|
|
|
|
|
pthread_cond_init(&queue->cond, NULL);
|
2012-10-11 23:37:51 +02:00
|
|
|
queue->display = display;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
wl_event_queue_release(struct wl_event_queue *queue)
|
|
|
|
|
{
|
|
|
|
|
struct wl_closure *closure;
|
|
|
|
|
|
|
|
|
|
while (!wl_list_empty(&queue->event_list)) {
|
|
|
|
|
closure = container_of(queue->event_list.next,
|
|
|
|
|
struct wl_closure, link);
|
|
|
|
|
wl_list_remove(&closure->link);
|
|
|
|
|
wl_closure_destroy(closure);
|
|
|
|
|
}
|
|
|
|
|
pthread_cond_destroy(&queue->cond);
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Destroy an event queue
|
|
|
|
|
*
|
|
|
|
|
* \param queue The event queue to be destroyed
|
|
|
|
|
*
|
|
|
|
|
* Destroy the given event queue. Any pending event on that queue is
|
|
|
|
|
* discarded.
|
|
|
|
|
*
|
2012-10-16 17:29:07 +03:00
|
|
|
* The \ref wl_display object used to create the queue should not be
|
|
|
|
|
* destroyed until all event queues created with it are destroyed with
|
|
|
|
|
* this function.
|
|
|
|
|
*
|
2012-10-12 17:28:57 +03:00
|
|
|
* \memberof wl_event_queue
|
|
|
|
|
*/
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
WL_EXPORT void
|
|
|
|
|
wl_event_queue_destroy(struct wl_event_queue *queue)
|
|
|
|
|
{
|
2012-10-11 23:37:51 +02:00
|
|
|
struct wl_display *display = queue->display;
|
|
|
|
|
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
|
|
|
|
wl_list_remove(&queue->link);
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
wl_event_queue_release(queue);
|
|
|
|
|
free(queue);
|
2012-10-11 23:37:51 +02:00
|
|
|
pthread_mutex_unlock(&display->mutex);
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Create a new event queue for this display
|
|
|
|
|
*
|
|
|
|
|
* \param display The display context object
|
2012-10-15 17:53:23 +03:00
|
|
|
* \return A new event queue associated with this display or NULL on
|
2012-10-12 17:28:57 +03:00
|
|
|
* failure.
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
WL_EXPORT struct wl_event_queue *
|
|
|
|
|
wl_display_create_queue(struct wl_display *display)
|
|
|
|
|
{
|
|
|
|
|
struct wl_event_queue *queue;
|
|
|
|
|
|
|
|
|
|
queue = malloc(sizeof *queue);
|
|
|
|
|
if (queue == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2012-10-11 23:37:51 +02:00
|
|
|
wl_event_queue_init(queue, display);
|
|
|
|
|
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
|
|
|
|
wl_list_insert(&display->event_queue_list, &queue->link);
|
|
|
|
|
pthread_mutex_unlock(&display->mutex);
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
|
|
|
|
|
return queue;
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-15 17:53:23 +03:00
|
|
|
/** Create a proxy object with a given interface
|
|
|
|
|
*
|
|
|
|
|
* \param factory Factory proxy object
|
|
|
|
|
* \param interface Interface the proxy object should use
|
|
|
|
|
* \return A newly allocated proxy object or NULL on failure
|
|
|
|
|
*
|
|
|
|
|
* This function creates a new proxy object with the supplied interface. The
|
|
|
|
|
* proxy object will have an id assigned from the client id space. The id
|
|
|
|
|
* should be created on the compositor side by sending an appropriate request
|
|
|
|
|
* with \ref wl_proxy_marshal().
|
|
|
|
|
*
|
|
|
|
|
* The proxy will inherit the display and event queue of the factory object.
|
|
|
|
|
*
|
|
|
|
|
* \note This should not normally be used by non-generated code.
|
|
|
|
|
*
|
|
|
|
|
* \sa wl_display, wl_event_queue, wl_proxy_marshal()
|
2012-10-12 17:28:57 +03:00
|
|
|
*
|
|
|
|
|
* \memberof wl_proxy
|
|
|
|
|
*/
|
2010-08-10 14:02:48 -04:00
|
|
|
WL_EXPORT struct wl_proxy *
|
2011-08-19 13:44:01 -04:00
|
|
|
wl_proxy_create(struct wl_proxy *factory, const struct wl_interface *interface)
|
2008-12-30 11:03:33 -05:00
|
|
|
{
|
|
|
|
|
struct wl_proxy *proxy;
|
2011-08-19 13:44:01 -04:00
|
|
|
struct wl_display *display = factory->display;
|
2008-12-30 11:03:33 -05:00
|
|
|
|
|
|
|
|
proxy = malloc(sizeof *proxy);
|
|
|
|
|
if (proxy == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2010-12-01 17:07:41 -05:00
|
|
|
proxy->object.interface = interface;
|
2011-02-18 15:28:54 -05:00
|
|
|
proxy->object.implementation = NULL;
|
2012-10-04 17:42:49 -04:00
|
|
|
proxy->display = display;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
proxy->queue = factory->queue;
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
proxy->flags = 0;
|
|
|
|
|
proxy->refcount = 1;
|
2012-10-04 17:42:49 -04:00
|
|
|
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
2011-11-18 21:59:36 -05:00
|
|
|
proxy->object.id = wl_map_insert_new(&display->objects,
|
|
|
|
|
WL_MAP_CLIENT_SIDE, proxy);
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_unlock(&display->mutex);
|
2011-11-18 21:59:36 -05:00
|
|
|
|
|
|
|
|
return proxy;
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-11 14:55:59 +03:00
|
|
|
/* The caller should hold the display lock */
|
|
|
|
|
static struct wl_proxy *
|
2011-11-18 21:59:36 -05:00
|
|
|
wl_proxy_create_for_id(struct wl_proxy *factory,
|
|
|
|
|
uint32_t id, const struct wl_interface *interface)
|
|
|
|
|
{
|
|
|
|
|
struct wl_proxy *proxy;
|
|
|
|
|
struct wl_display *display = factory->display;
|
|
|
|
|
|
|
|
|
|
proxy = malloc(sizeof *proxy);
|
|
|
|
|
if (proxy == NULL)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
proxy->object.interface = interface;
|
|
|
|
|
proxy->object.implementation = NULL;
|
2011-11-15 08:58:34 -05:00
|
|
|
proxy->object.id = id;
|
2008-12-30 11:03:33 -05:00
|
|
|
proxy->display = display;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
proxy->queue = factory->queue;
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
proxy->flags = 0;
|
|
|
|
|
proxy->refcount = 1;
|
2012-10-04 17:42:49 -04:00
|
|
|
|
2011-11-15 08:58:34 -05:00
|
|
|
wl_map_insert_at(&display->objects, id, proxy);
|
2008-12-30 11:03:33 -05:00
|
|
|
|
|
|
|
|
return proxy;
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Destroy a proxy object
|
|
|
|
|
*
|
|
|
|
|
* \param proxy The proxy to be destroyed
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_proxy
|
|
|
|
|
*/
|
2010-09-02 20:22:42 -04:00
|
|
|
WL_EXPORT void
|
|
|
|
|
wl_proxy_destroy(struct wl_proxy *proxy)
|
|
|
|
|
{
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
struct wl_display *display = proxy->display;
|
|
|
|
|
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
2012-10-04 17:42:49 -04:00
|
|
|
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
if (proxy->flags & WL_PROXY_FLAG_ID_DELETED)
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
wl_map_remove(&proxy->display->objects, proxy->object.id);
|
|
|
|
|
else if (proxy->object.id < WL_SERVER_ID_START)
|
2011-11-18 21:59:36 -05:00
|
|
|
wl_map_insert_at(&proxy->display->objects,
|
|
|
|
|
proxy->object.id, WL_ZOMBIE_OBJECT);
|
|
|
|
|
else
|
|
|
|
|
wl_map_insert_at(&proxy->display->objects,
|
|
|
|
|
proxy->object.id, NULL);
|
2012-10-04 17:42:49 -04:00
|
|
|
|
|
|
|
|
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
proxy->flags |= WL_PROXY_FLAG_DESTROYED;
|
|
|
|
|
|
|
|
|
|
proxy->refcount--;
|
|
|
|
|
if (!proxy->refcount)
|
|
|
|
|
free(proxy);
|
|
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&display->mutex);
|
2010-09-02 20:22:42 -04:00
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Set a proxy's listener
|
|
|
|
|
*
|
|
|
|
|
* \param proxy The proxy object
|
|
|
|
|
* \param implementation The listener to be added to proxy
|
|
|
|
|
* \param data User data to be associated with the proxy
|
|
|
|
|
* \return 0 on success or -1 on failure
|
|
|
|
|
*
|
|
|
|
|
* Set proxy's listener to \c implementation and its user data to
|
2012-11-22 18:09:32 -02:00
|
|
|
* \c data. If a listener has already been set, this function
|
2012-10-12 17:28:57 +03:00
|
|
|
* fails and nothing is changed.
|
|
|
|
|
*
|
|
|
|
|
* \c implementation is a vector of function pointers. For an opcode
|
2012-11-22 18:09:32 -02:00
|
|
|
* \c n, \c implementation[n] should point to the handler of \c n for
|
2012-10-12 17:28:57 +03:00
|
|
|
* the given object.
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_proxy
|
|
|
|
|
*/
|
2010-08-10 10:53:44 -04:00
|
|
|
WL_EXPORT int
|
2010-08-10 14:02:48 -04:00
|
|
|
wl_proxy_add_listener(struct wl_proxy *proxy,
|
|
|
|
|
void (**implementation)(void), void *data)
|
2008-12-21 23:37:12 -05:00
|
|
|
{
|
2011-02-18 15:28:54 -05:00
|
|
|
if (proxy->object.implementation) {
|
|
|
|
|
fprintf(stderr, "proxy already has listener\n");
|
2008-12-30 11:03:33 -05:00
|
|
|
return -1;
|
2011-02-18 15:28:54 -05:00
|
|
|
}
|
2008-12-30 11:03:33 -05:00
|
|
|
|
2011-02-18 15:28:54 -05:00
|
|
|
proxy->object.implementation = implementation;
|
|
|
|
|
proxy->user_data = data;
|
2008-12-30 11:03:33 -05:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-15 17:53:23 +03:00
|
|
|
/** Prepare a request to be sent to the compositor
|
|
|
|
|
*
|
|
|
|
|
* \param proxy The proxy object
|
|
|
|
|
* \param opcode Opcode of the request to be sent
|
|
|
|
|
* \param ... Extra arguments for the given request
|
|
|
|
|
*
|
|
|
|
|
* Translates the request given by opcode and the extra arguments into the
|
|
|
|
|
* wire format and write it to the connection buffer.
|
|
|
|
|
*
|
|
|
|
|
* The example below creates a proxy object with the wl_surface_interface
|
|
|
|
|
* using a wl_compositor factory interface and sends the
|
|
|
|
|
* \c compositor.create_surface request using \ref wl_proxy_marshal(). Note
|
|
|
|
|
* the \c id is the extra argument to the request as specified by the
|
|
|
|
|
* protocol.
|
|
|
|
|
*
|
|
|
|
|
* \code
|
|
|
|
|
* id = wl_proxy_create((struct wl_proxy *) wl_compositor,
|
|
|
|
|
* &wl_surface_interface);
|
|
|
|
|
* wl_proxy_marshal((struct wl_proxy *) wl_compositor,
|
|
|
|
|
* WL_COMPOSITOR_CREATE_SURFACE, id);
|
|
|
|
|
* \endcode
|
|
|
|
|
*
|
|
|
|
|
* \note This should not normally be used by non-generated code.
|
|
|
|
|
*
|
|
|
|
|
* \sa wl_proxy_create()
|
2012-10-12 17:28:57 +03:00
|
|
|
*
|
|
|
|
|
* \memberof wl_proxy
|
|
|
|
|
*/
|
2010-08-09 21:25:50 -04:00
|
|
|
WL_EXPORT void
|
2008-12-30 11:03:33 -05:00
|
|
|
wl_proxy_marshal(struct wl_proxy *proxy, uint32_t opcode, ...)
|
|
|
|
|
{
|
2012-06-12 17:45:25 -04:00
|
|
|
struct wl_closure *closure;
|
2008-12-30 11:03:33 -05:00
|
|
|
va_list ap;
|
|
|
|
|
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_lock(&proxy->display->mutex);
|
|
|
|
|
|
2008-12-30 11:03:33 -05:00
|
|
|
va_start(ap, opcode);
|
2012-06-12 17:45:25 -04:00
|
|
|
closure = wl_closure_vmarshal(&proxy->object, opcode, ap,
|
|
|
|
|
&proxy->object.interface->methods[opcode]);
|
2008-12-30 11:03:33 -05:00
|
|
|
va_end(ap);
|
2010-09-07 21:34:45 -04:00
|
|
|
|
2012-06-12 17:45:25 -04:00
|
|
|
if (closure == NULL) {
|
2011-12-16 10:29:36 +02:00
|
|
|
fprintf(stderr, "Error marshalling request\n");
|
|
|
|
|
abort();
|
|
|
|
|
}
|
|
|
|
|
|
2012-07-23 19:54:42 +01:00
|
|
|
if (wl_debug)
|
|
|
|
|
wl_closure_print(closure, &proxy->object, true);
|
|
|
|
|
|
2012-06-12 17:45:25 -04:00
|
|
|
if (wl_closure_send(closure, proxy->display->connection)) {
|
2012-02-29 11:07:48 -05:00
|
|
|
fprintf(stderr, "Error sending request: %m\n");
|
|
|
|
|
abort();
|
|
|
|
|
}
|
2011-02-10 12:27:35 -05:00
|
|
|
|
2012-06-12 17:45:25 -04:00
|
|
|
wl_closure_destroy(closure);
|
2012-10-04 17:42:49 -04:00
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&proxy->display->mutex);
|
2008-12-30 11:03:33 -05:00
|
|
|
}
|
|
|
|
|
|
2008-12-24 19:30:25 -05:00
|
|
|
static void
|
2011-05-11 10:57:06 -04:00
|
|
|
display_handle_error(void *data,
|
|
|
|
|
struct wl_display *display, struct wl_object *object,
|
|
|
|
|
uint32_t code, const char *message)
|
2008-12-24 19:30:25 -05:00
|
|
|
{
|
2012-10-11 23:37:42 +02:00
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
wl_log("%s@%u: error %d: %s\n",
|
|
|
|
|
object->interface->name, object->id, code, message);
|
|
|
|
|
|
|
|
|
|
switch (code) {
|
|
|
|
|
case WL_DISPLAY_ERROR_INVALID_OBJECT:
|
|
|
|
|
case WL_DISPLAY_ERROR_INVALID_METHOD:
|
|
|
|
|
err = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
case WL_DISPLAY_ERROR_NO_MEMORY:
|
|
|
|
|
err = -ENOMEM;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
err = -EFAULT;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-11 23:37:53 +02:00
|
|
|
wl_display_fatal_error(display, err);
|
2008-12-24 19:30:25 -05:00
|
|
|
}
|
|
|
|
|
|
2011-11-15 22:20:28 -05:00
|
|
|
static void
|
|
|
|
|
display_handle_delete_id(void *data, struct wl_display *display, uint32_t id)
|
|
|
|
|
{
|
|
|
|
|
struct wl_proxy *proxy;
|
|
|
|
|
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_lock(&display->mutex);
|
|
|
|
|
|
2011-11-15 22:20:28 -05:00
|
|
|
proxy = wl_map_lookup(&display->objects, id);
|
|
|
|
|
if (proxy != WL_ZOMBIE_OBJECT)
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
proxy->flags |= WL_PROXY_FLAG_ID_DELETED;
|
2011-11-15 22:20:28 -05:00
|
|
|
else
|
|
|
|
|
wl_map_remove(&display->objects, id);
|
2012-10-04 17:42:49 -04:00
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&display->mutex);
|
2011-11-15 22:20:28 -05:00
|
|
|
}
|
|
|
|
|
|
2008-12-24 19:30:25 -05:00
|
|
|
static const struct wl_display_listener display_listener = {
|
2011-05-11 10:57:06 -04:00
|
|
|
display_handle_error,
|
2011-11-15 22:20:28 -05:00
|
|
|
display_handle_delete_id
|
2008-12-24 19:30:25 -05:00
|
|
|
};
|
|
|
|
|
|
2011-04-11 09:14:43 -04:00
|
|
|
static int
|
2012-08-14 13:16:10 -04:00
|
|
|
connect_to_socket(const char *name)
|
2008-10-07 10:10:36 -04:00
|
|
|
{
|
2008-12-07 15:22:22 -05:00
|
|
|
struct sockaddr_un addr;
|
2008-10-07 10:10:36 -04:00
|
|
|
socklen_t size;
|
2010-12-01 15:36:20 -05:00
|
|
|
const char *runtime_dir;
|
2012-08-14 13:16:10 -04:00
|
|
|
int name_size, fd;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2010-12-01 15:36:20 -05:00
|
|
|
runtime_dir = getenv("XDG_RUNTIME_DIR");
|
2012-06-06 14:30:18 +03:00
|
|
|
if (!runtime_dir) {
|
2010-12-01 15:36:20 -05:00
|
|
|
fprintf(stderr,
|
2012-06-06 14:30:18 +03:00
|
|
|
"error: XDG_RUNTIME_DIR not set in the environment.\n");
|
|
|
|
|
|
|
|
|
|
/* to prevent programs reporting
|
|
|
|
|
* "failed to create display: Success" */
|
|
|
|
|
errno = ENOENT;
|
|
|
|
|
return -1;
|
2010-12-01 15:36:20 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (name == NULL)
|
|
|
|
|
name = getenv("WAYLAND_DISPLAY");
|
|
|
|
|
if (name == NULL)
|
|
|
|
|
name = "wayland-0";
|
|
|
|
|
|
2012-08-14 13:16:10 -04:00
|
|
|
fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
|
|
|
|
|
if (fd < 0)
|
2012-06-06 14:30:18 +03:00
|
|
|
return -1;
|
|
|
|
|
|
2010-12-01 15:36:20 -05:00
|
|
|
memset(&addr, 0, sizeof addr);
|
2008-12-07 15:22:22 -05:00
|
|
|
addr.sun_family = AF_LOCAL;
|
2010-12-01 15:36:20 -05:00
|
|
|
name_size =
|
|
|
|
|
snprintf(addr.sun_path, sizeof addr.sun_path,
|
|
|
|
|
"%s/%s", runtime_dir, name) + 1;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-06-15 21:39:50 +00:00
|
|
|
assert(name_size > 0);
|
|
|
|
|
if (name_size > (int)sizeof addr.sun_path) {
|
|
|
|
|
fprintf(stderr,
|
|
|
|
|
"error: socket path \"%s/%s\" plus null terminator"
|
|
|
|
|
" exceeds 108 bytes\n", runtime_dir, name);
|
2012-08-14 13:16:10 -04:00
|
|
|
close(fd);
|
2012-06-15 21:39:50 +00:00
|
|
|
/* to prevent programs reporting
|
|
|
|
|
* "failed to add socket: Success" */
|
|
|
|
|
errno = ENAMETOOLONG;
|
|
|
|
|
return -1;
|
|
|
|
|
};
|
|
|
|
|
|
2008-12-07 15:22:22 -05:00
|
|
|
size = offsetof (struct sockaddr_un, sun_path) + name_size;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-08-14 13:16:10 -04:00
|
|
|
if (connect(fd, (struct sockaddr *) &addr, size) < 0) {
|
|
|
|
|
close(fd);
|
2011-04-11 09:14:43 -04:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-14 13:16:10 -04:00
|
|
|
return fd;
|
2011-04-11 09:14:43 -04:00
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Connect to Wayland display on an already open fd
|
|
|
|
|
*
|
|
|
|
|
* \param fd The fd to use for the connection
|
|
|
|
|
* \return A \ref wl_display object or \c NULL on failure
|
|
|
|
|
*
|
2012-10-15 17:50:36 -04:00
|
|
|
* The wl_display takes ownership of the fd and will close it when the
|
|
|
|
|
* display is destroyed. The fd will also be closed in case of
|
|
|
|
|
* failure.
|
|
|
|
|
*
|
2012-10-12 17:28:57 +03:00
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
2011-04-11 09:14:43 -04:00
|
|
|
WL_EXPORT struct wl_display *
|
2012-08-14 13:16:10 -04:00
|
|
|
wl_display_connect_to_fd(int fd)
|
2011-04-11 09:14:43 -04:00
|
|
|
{
|
|
|
|
|
struct wl_display *display;
|
|
|
|
|
const char *debug;
|
|
|
|
|
|
|
|
|
|
debug = getenv("WAYLAND_DEBUG");
|
2012-11-21 17:14:55 -05:00
|
|
|
if (debug && (strstr(debug, "client") || strstr(debug, "1")))
|
2011-04-11 09:14:43 -04:00
|
|
|
wl_debug = 1;
|
|
|
|
|
|
|
|
|
|
display = malloc(sizeof *display);
|
2012-10-15 17:50:36 -04:00
|
|
|
if (display == NULL) {
|
|
|
|
|
close(fd);
|
2011-04-11 09:14:43 -04:00
|
|
|
return NULL;
|
2012-10-15 17:50:36 -04:00
|
|
|
}
|
2011-04-11 09:14:43 -04:00
|
|
|
|
|
|
|
|
memset(display, 0, sizeof *display);
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-08-14 13:16:10 -04:00
|
|
|
display->fd = fd;
|
2011-08-19 22:50:53 -04:00
|
|
|
wl_map_init(&display->objects);
|
2012-10-11 23:37:51 +02:00
|
|
|
wl_event_queue_init(&display->queue, display);
|
|
|
|
|
wl_list_init(&display->event_queue_list);
|
2012-10-11 17:11:54 -04:00
|
|
|
pthread_mutex_init(&display->mutex, NULL);
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2011-11-18 21:59:36 -05:00
|
|
|
wl_map_insert_new(&display->objects, WL_MAP_CLIENT_SIDE, NULL);
|
2011-08-19 22:50:53 -04:00
|
|
|
|
2010-12-01 17:07:41 -05:00
|
|
|
display->proxy.object.interface = &wl_display_interface;
|
2011-11-18 21:59:36 -05:00
|
|
|
display->proxy.object.id =
|
|
|
|
|
wl_map_insert_new(&display->objects,
|
|
|
|
|
WL_MAP_CLIENT_SIDE, display);
|
2008-12-21 21:50:23 -05:00
|
|
|
display->proxy.display = display;
|
2011-08-19 22:50:53 -04:00
|
|
|
display->proxy.object.implementation = (void(**)(void)) &display_listener;
|
2011-02-18 15:28:54 -05:00
|
|
|
display->proxy.user_data = display;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
display->proxy.queue = &display->queue;
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
display->proxy.flags = 0;
|
|
|
|
|
display->proxy.refcount = 1;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-10-04 16:54:22 -04:00
|
|
|
display->connection = wl_connection_create(display->fd);
|
2011-03-11 14:43:10 +02:00
|
|
|
if (display->connection == NULL) {
|
2011-08-19 22:50:53 -04:00
|
|
|
wl_map_release(&display->objects);
|
2011-03-11 14:43:10 +02:00
|
|
|
close(display->fd);
|
|
|
|
|
free(display);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2011-04-14 10:38:44 -04:00
|
|
|
|
2008-10-08 13:32:07 -04:00
|
|
|
return display;
|
2008-10-07 10:10:36 -04:00
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Connect to a Wayland display
|
|
|
|
|
*
|
|
|
|
|
* \param name Name of the Wayland display to connect to
|
|
|
|
|
* \return A \ref wl_display object or \c NULL on failure
|
|
|
|
|
*
|
|
|
|
|
* Connect to the Wayland display named \c name. If \c name is \c NULL,
|
|
|
|
|
* its value will bee replaced with the WAYLAND_DISPLAY environment
|
|
|
|
|
* variable if it is set, otherwise display "wayland-0" will be used.
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
2012-08-14 13:16:10 -04:00
|
|
|
WL_EXPORT struct wl_display *
|
|
|
|
|
wl_display_connect(const char *name)
|
|
|
|
|
{
|
|
|
|
|
char *connection, *end;
|
|
|
|
|
int flags, fd;
|
|
|
|
|
|
|
|
|
|
connection = getenv("WAYLAND_SOCKET");
|
|
|
|
|
if (connection) {
|
|
|
|
|
fd = strtol(connection, &end, 0);
|
|
|
|
|
if (*end != '\0')
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
flags = fcntl(fd, F_GETFD);
|
|
|
|
|
if (flags != -1)
|
|
|
|
|
fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
|
|
|
|
|
unsetenv("WAYLAND_SOCKET");
|
|
|
|
|
} else {
|
|
|
|
|
fd = connect_to_socket(name);
|
|
|
|
|
if (fd < 0)
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-15 17:50:36 -04:00
|
|
|
return wl_display_connect_to_fd(fd);
|
2012-08-14 13:16:10 -04:00
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Close a connection to a Wayland display
|
|
|
|
|
*
|
|
|
|
|
* \param display The display context object
|
|
|
|
|
*
|
|
|
|
|
* Close the connection to \c display and free all resources associated
|
|
|
|
|
* with it.
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
2008-11-08 15:39:41 -05:00
|
|
|
WL_EXPORT void
|
2012-02-27 17:10:03 +01:00
|
|
|
wl_display_disconnect(struct wl_display *display)
|
2008-10-07 10:10:36 -04:00
|
|
|
{
|
2008-10-08 13:32:07 -04:00
|
|
|
wl_connection_destroy(display->connection);
|
2011-08-19 22:50:53 -04:00
|
|
|
wl_map_release(&display->objects);
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
wl_event_queue_release(&display->queue);
|
2012-10-11 17:11:54 -04:00
|
|
|
pthread_mutex_destroy(&display->mutex);
|
2012-10-11 23:37:53 +02:00
|
|
|
if (display->fd > 0)
|
|
|
|
|
close(display->fd);
|
2012-08-14 13:16:10 -04:00
|
|
|
|
2008-10-08 13:32:07 -04:00
|
|
|
free(display);
|
2008-10-07 10:10:36 -04:00
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Get a display context's file descriptor
|
|
|
|
|
*
|
|
|
|
|
* \param display The display context object
|
|
|
|
|
* \return Display object file descriptor
|
|
|
|
|
*
|
|
|
|
|
* Return the file descriptor associated with a display so it can be
|
|
|
|
|
* integrated into the client's main loop.
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
2008-11-08 15:39:41 -05:00
|
|
|
WL_EXPORT int
|
2012-10-04 16:54:22 -04:00
|
|
|
wl_display_get_fd(struct wl_display *display)
|
2008-10-07 10:10:36 -04:00
|
|
|
{
|
2008-10-08 13:32:07 -04:00
|
|
|
return display->fd;
|
2008-10-07 10:10:36 -04:00
|
|
|
}
|
|
|
|
|
|
2011-07-29 19:51:22 -07:00
|
|
|
static void
|
Switch protocol to using serial numbers for ordering events and requests
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
2012-04-11 22:25:51 -04:00
|
|
|
sync_callback(void *data, struct wl_callback *callback, uint32_t serial)
|
2010-09-03 14:46:38 -04:00
|
|
|
{
|
2011-07-29 19:51:22 -07:00
|
|
|
int *done = data;
|
2010-09-03 14:46:38 -04:00
|
|
|
|
2011-07-29 19:51:22 -07:00
|
|
|
*done = 1;
|
|
|
|
|
wl_callback_destroy(callback);
|
2010-09-03 14:46:38 -04:00
|
|
|
}
|
|
|
|
|
|
2011-07-29 19:51:22 -07:00
|
|
|
static const struct wl_callback_listener sync_listener = {
|
|
|
|
|
sync_callback
|
|
|
|
|
};
|
2010-09-03 14:46:38 -04:00
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Block until all pending request are processed by the server
|
|
|
|
|
*
|
|
|
|
|
* \param display The display context object
|
2012-10-16 17:29:08 +03:00
|
|
|
* \return The number of dispatched events on success or -1 on failure
|
2012-10-12 17:28:57 +03:00
|
|
|
*
|
|
|
|
|
* Blocks until the server process all currently issued requests and
|
|
|
|
|
* sends out pending events on all event queues.
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
2012-10-11 23:37:53 +02:00
|
|
|
WL_EXPORT int
|
2011-07-29 19:51:22 -07:00
|
|
|
wl_display_roundtrip(struct wl_display *display)
|
|
|
|
|
{
|
|
|
|
|
struct wl_callback *callback;
|
2012-10-11 23:37:53 +02:00
|
|
|
int done, ret = 0;
|
2011-07-29 19:51:22 -07:00
|
|
|
|
|
|
|
|
done = 0;
|
|
|
|
|
callback = wl_display_sync(display);
|
|
|
|
|
wl_callback_add_listener(callback, &sync_listener, &done);
|
2012-11-26 23:25:53 +01:00
|
|
|
while (!done && ret >= 0)
|
2012-10-11 23:37:53 +02:00
|
|
|
ret = wl_display_dispatch(display);
|
|
|
|
|
|
2012-11-26 23:25:53 +01:00
|
|
|
if (ret == -1 && !done)
|
|
|
|
|
wl_callback_destroy(callback);
|
|
|
|
|
|
2012-10-11 23:37:53 +02:00
|
|
|
return ret;
|
2010-09-03 14:46:38 -04:00
|
|
|
}
|
|
|
|
|
|
2012-06-28 22:01:58 -04:00
|
|
|
static int
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
create_proxies(struct wl_proxy *sender, struct wl_closure *closure)
|
2012-06-28 22:01:58 -04:00
|
|
|
{
|
|
|
|
|
struct wl_proxy *proxy;
|
|
|
|
|
const char *signature;
|
2012-07-23 19:54:41 +01:00
|
|
|
struct argument_details arg;
|
2012-06-28 22:01:58 -04:00
|
|
|
uint32_t id;
|
|
|
|
|
int i;
|
2012-07-23 19:54:41 +01:00
|
|
|
int count;
|
2012-06-28 22:01:58 -04:00
|
|
|
|
|
|
|
|
signature = closure->message->signature;
|
2012-07-23 19:54:41 +01:00
|
|
|
count = arg_count_for_signature(signature) + 2;
|
|
|
|
|
for (i = 2; i < count; i++) {
|
|
|
|
|
signature = get_next_argument(signature, &arg);
|
|
|
|
|
switch (arg.type) {
|
2012-06-28 22:01:58 -04:00
|
|
|
case 'n':
|
2012-07-23 19:54:41 +01:00
|
|
|
id = **(uint32_t **) closure->args[i];
|
|
|
|
|
if (id == 0) {
|
|
|
|
|
*(void **) closure->args[i] = NULL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
proxy = wl_proxy_create_for_id(sender, id,
|
2012-07-23 19:54:41 +01:00
|
|
|
closure->message->types[i - 2]);
|
2012-06-28 22:01:58 -04:00
|
|
|
if (proxy == NULL)
|
|
|
|
|
return -1;
|
2012-07-23 19:54:41 +01:00
|
|
|
*(void **) closure->args[i] = proxy;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
2012-06-28 22:01:58 -04:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
static void
|
|
|
|
|
increase_closure_args_refcount(struct wl_closure *closure)
|
|
|
|
|
{
|
|
|
|
|
const char *signature;
|
|
|
|
|
struct argument_details arg;
|
|
|
|
|
int i, count;
|
|
|
|
|
struct wl_proxy *proxy;
|
|
|
|
|
|
|
|
|
|
signature = closure->message->signature;
|
|
|
|
|
count = arg_count_for_signature(signature) + 2;
|
|
|
|
|
for (i = 2; i < count; i++) {
|
|
|
|
|
signature = get_next_argument(signature, &arg);
|
|
|
|
|
switch (arg.type) {
|
|
|
|
|
case 'n':
|
|
|
|
|
case 'o':
|
|
|
|
|
proxy = *(struct wl_proxy **) closure->args[i];
|
|
|
|
|
if (proxy)
|
|
|
|
|
proxy->refcount++;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-04 17:34:18 -04:00
|
|
|
static int
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
queue_event(struct wl_display *display, int len)
|
2008-10-07 10:10:36 -04:00
|
|
|
{
|
2012-10-04 17:34:18 -04:00
|
|
|
uint32_t p[2], id;
|
|
|
|
|
int opcode, size;
|
2008-12-30 11:03:33 -05:00
|
|
|
struct wl_proxy *proxy;
|
2012-06-12 17:45:25 -04:00
|
|
|
struct wl_closure *closure;
|
2010-09-01 17:18:33 -04:00
|
|
|
const struct wl_message *message;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-10-04 17:34:18 -04:00
|
|
|
wl_connection_copy(display->connection, p, sizeof p);
|
|
|
|
|
id = p[0];
|
|
|
|
|
opcode = p[1] & 0xffff;
|
|
|
|
|
size = p[1] >> 16;
|
|
|
|
|
if (len < size)
|
|
|
|
|
return 0;
|
2008-12-30 11:03:33 -05:00
|
|
|
|
2012-10-04 17:34:18 -04:00
|
|
|
proxy = wl_map_lookup(&display->objects, id);
|
2011-11-15 22:20:28 -05:00
|
|
|
if (proxy == WL_ZOMBIE_OBJECT) {
|
|
|
|
|
wl_connection_consume(display->connection, size);
|
2012-10-04 17:34:18 -04:00
|
|
|
return size;
|
2012-10-11 17:12:50 -04:00
|
|
|
} else if (proxy == NULL) {
|
2010-08-30 09:47:36 -04:00
|
|
|
wl_connection_consume(display->connection, size);
|
2012-10-04 17:34:18 -04:00
|
|
|
return size;
|
2010-08-30 09:47:36 -04:00
|
|
|
}
|
|
|
|
|
|
2010-12-01 17:07:41 -05:00
|
|
|
message = &proxy->object.interface->events[opcode];
|
2012-06-12 17:45:25 -04:00
|
|
|
closure = wl_connection_demarshal(display->connection, size,
|
|
|
|
|
&display->objects, message);
|
2012-10-11 23:37:53 +02:00
|
|
|
if (!closure)
|
|
|
|
|
return -1;
|
2010-08-30 09:47:36 -04:00
|
|
|
|
2012-10-11 23:37:53 +02:00
|
|
|
if (create_proxies(proxy, closure) < 0) {
|
|
|
|
|
wl_closure_destroy(closure);
|
|
|
|
|
return -1;
|
2011-07-18 02:00:24 -04:00
|
|
|
}
|
|
|
|
|
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
if (wl_closure_lookup_objects(closure, &display->objects) != 0) {
|
|
|
|
|
wl_closure_destroy(closure);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
increase_closure_args_refcount(closure);
|
|
|
|
|
proxy->refcount++;
|
|
|
|
|
closure->proxy = proxy;
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
if (wl_list_empty(&proxy->queue->event_list))
|
|
|
|
|
pthread_cond_signal(&proxy->queue->cond);
|
|
|
|
|
wl_list_insert(proxy->queue->event_list.prev, &closure->link);
|
2012-10-04 17:34:18 -04:00
|
|
|
|
|
|
|
|
return size;
|
|
|
|
|
}
|
|
|
|
|
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
static void
|
|
|
|
|
decrease_closure_args_refcount(struct wl_closure *closure)
|
|
|
|
|
{
|
|
|
|
|
const char *signature;
|
|
|
|
|
struct argument_details arg;
|
|
|
|
|
int i, count;
|
|
|
|
|
struct wl_proxy *proxy;
|
|
|
|
|
|
|
|
|
|
signature = closure->message->signature;
|
|
|
|
|
count = arg_count_for_signature(signature) + 2;
|
|
|
|
|
for (i = 2; i < count; i++) {
|
|
|
|
|
signature = get_next_argument(signature, &arg);
|
|
|
|
|
switch (arg.type) {
|
|
|
|
|
case 'n':
|
|
|
|
|
case 'o':
|
|
|
|
|
proxy = *(struct wl_proxy **) closure->args[i];
|
|
|
|
|
if (proxy) {
|
|
|
|
|
if (proxy->flags & WL_PROXY_FLAG_DESTROYED)
|
|
|
|
|
*(void **) closure->args[i] = NULL;
|
|
|
|
|
|
|
|
|
|
proxy->refcount--;
|
|
|
|
|
if (!proxy->refcount)
|
|
|
|
|
free(proxy);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-04 17:34:18 -04:00
|
|
|
static void
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
dispatch_event(struct wl_display *display, struct wl_event_queue *queue)
|
2012-10-04 17:34:18 -04:00
|
|
|
{
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
struct wl_closure *closure;
|
2012-10-04 17:34:18 -04:00
|
|
|
struct wl_proxy *proxy;
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
int opcode;
|
|
|
|
|
bool proxy_destroyed;
|
2012-10-04 17:34:18 -04:00
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
closure = container_of(queue->event_list.next,
|
|
|
|
|
struct wl_closure, link);
|
2012-10-04 17:34:18 -04:00
|
|
|
wl_list_remove(&closure->link);
|
|
|
|
|
opcode = closure->buffer[1] & 0xffff;
|
|
|
|
|
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
/* Verify that the receiving object is still valid by checking if has
|
|
|
|
|
* been destroyed by the application. */
|
|
|
|
|
|
|
|
|
|
decrease_closure_args_refcount(closure);
|
|
|
|
|
proxy = closure->proxy;
|
|
|
|
|
proxy_destroyed = !!(proxy->flags & WL_PROXY_FLAG_DESTROYED);
|
|
|
|
|
|
|
|
|
|
proxy->refcount--;
|
|
|
|
|
if (!proxy->refcount)
|
|
|
|
|
free(proxy);
|
|
|
|
|
|
|
|
|
|
if (proxy_destroyed) {
|
|
|
|
|
wl_closure_destroy(closure);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2012-10-04 17:42:49 -04:00
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
pthread_mutex_unlock(&display->mutex);
|
2012-10-04 17:34:18 -04:00
|
|
|
|
client: Keep track of proxy validity and number of reference holders
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>
2012-11-03 22:26:10 +01:00
|
|
|
if (proxy->object.implementation) {
|
2012-10-09 12:14:34 -04:00
|
|
|
if (wl_debug)
|
|
|
|
|
wl_closure_print(closure, &proxy->object, false);
|
|
|
|
|
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
wl_closure_invoke(closure, &proxy->object,
|
|
|
|
|
proxy->object.implementation[opcode],
|
|
|
|
|
proxy->user_data);
|
2012-10-09 12:14:34 -04:00
|
|
|
}
|
|
|
|
|
|
2012-06-12 17:45:25 -04:00
|
|
|
wl_closure_destroy(closure);
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
2008-10-07 10:10:36 -04:00
|
|
|
}
|
|
|
|
|
|
2012-10-11 17:15:08 -04:00
|
|
|
static int
|
|
|
|
|
dispatch_queue(struct wl_display *display,
|
|
|
|
|
struct wl_event_queue *queue, int block)
|
2008-10-07 10:10:36 -04:00
|
|
|
{
|
2012-10-11 23:37:53 +02:00
|
|
|
int len, size, count, ret;
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_lock(&display->mutex);
|
|
|
|
|
|
2012-10-11 23:37:53 +02:00
|
|
|
if (display->last_error)
|
|
|
|
|
goto err_unlock;
|
|
|
|
|
|
|
|
|
|
ret = wl_connection_flush(display->connection);
|
|
|
|
|
if (ret < 0 && errno != EAGAIN) {
|
|
|
|
|
display_fatal_error(display, errno);
|
|
|
|
|
goto err_unlock;
|
|
|
|
|
}
|
2011-01-22 20:41:07 +01:00
|
|
|
|
2012-10-11 17:15:08 -04:00
|
|
|
if (block && wl_list_empty(&queue->event_list) &&
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
pthread_equal(display->display_thread, pthread_self())) {
|
|
|
|
|
len = wl_connection_read(display->connection);
|
|
|
|
|
if (len == -1) {
|
2012-10-11 23:37:53 +02:00
|
|
|
display_fatal_error(display, errno);
|
|
|
|
|
goto err_unlock;
|
|
|
|
|
} else if (len == 0) {
|
|
|
|
|
display_fatal_error(display, EPIPE);
|
|
|
|
|
goto err_unlock;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
}
|
|
|
|
|
while (len >= 8) {
|
|
|
|
|
size = queue_event(display, len);
|
2012-10-11 23:37:53 +02:00
|
|
|
if (size == -1) {
|
|
|
|
|
display_fatal_error(display, errno);
|
|
|
|
|
goto err_unlock;
|
|
|
|
|
} else if (size == 0) {
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
break;
|
2012-10-11 23:37:53 +02:00
|
|
|
}
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
len -= size;
|
|
|
|
|
}
|
2012-10-11 17:15:08 -04:00
|
|
|
} else if (block && wl_list_empty(&queue->event_list)) {
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
pthread_cond_wait(&queue->cond, &display->mutex);
|
2012-10-11 23:37:53 +02:00
|
|
|
if (display->last_error)
|
|
|
|
|
goto err_unlock;
|
2012-10-04 17:42:49 -04:00
|
|
|
}
|
2011-10-20 15:05:11 -04:00
|
|
|
|
2012-10-11 23:37:53 +02:00
|
|
|
for (count = 0; !wl_list_empty(&queue->event_list); count++) {
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
dispatch_event(display, queue);
|
2012-10-11 23:37:53 +02:00
|
|
|
if (display->last_error)
|
|
|
|
|
goto err_unlock;
|
|
|
|
|
}
|
2008-10-07 10:10:36 -04:00
|
|
|
|
2012-10-04 17:42:49 -04:00
|
|
|
pthread_mutex_unlock(&display->mutex);
|
|
|
|
|
|
2012-10-15 11:38:20 -04:00
|
|
|
return count;
|
2012-10-11 23:37:53 +02:00
|
|
|
|
|
|
|
|
err_unlock:
|
|
|
|
|
errno = display->last_error;
|
|
|
|
|
pthread_mutex_unlock(&display->mutex);
|
|
|
|
|
|
|
|
|
|
return -1;
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Dispatch events in an event queue
|
|
|
|
|
*
|
|
|
|
|
* \param display The display context object
|
|
|
|
|
* \param queue The event queue to dispatch
|
2012-10-16 17:29:08 +03:00
|
|
|
* \return The number of dispatched events on success or -1 on failure
|
2012-10-12 17:28:57 +03:00
|
|
|
*
|
|
|
|
|
* Dispatch all incoming events for objects assigned to the given
|
|
|
|
|
* event queue. On failure -1 is returned and errno set appropriately.
|
|
|
|
|
*
|
2012-10-19 15:30:25 +03:00
|
|
|
* This function blocks if there are no events to dispatch. If calling from
|
|
|
|
|
* the main thread, it will block reading data from the display fd. For other
|
|
|
|
|
* threads this will block until the main thread queues events on the queue
|
|
|
|
|
* passed as argument.
|
|
|
|
|
*
|
2012-10-12 17:28:57 +03:00
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
2012-10-11 17:15:08 -04:00
|
|
|
WL_EXPORT int
|
|
|
|
|
wl_display_dispatch_queue(struct wl_display *display,
|
|
|
|
|
struct wl_event_queue *queue)
|
|
|
|
|
{
|
|
|
|
|
return dispatch_queue(display, queue, 1);
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-22 15:34:48 +02:00
|
|
|
/** Dispatch pending events in an event queue
|
|
|
|
|
*
|
|
|
|
|
* \param display The display context object
|
|
|
|
|
* \param queue The event queue to dispatch
|
|
|
|
|
* \return The number of dispatched events on success or -1 on failure
|
|
|
|
|
*
|
|
|
|
|
* Dispatch all incoming events for objects assigned to the given
|
|
|
|
|
* event queue. On failure -1 is returned and errno set appropriately.
|
|
|
|
|
* If there are no events queued, this functions return immediately.
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_display
|
2012-11-30 14:05:32 -05:00
|
|
|
* \since 1.0.2
|
2012-11-22 15:34:48 +02:00
|
|
|
*/
|
|
|
|
|
WL_EXPORT int
|
|
|
|
|
wl_display_dispatch_queue_pending(struct wl_display *display,
|
|
|
|
|
struct wl_event_queue *queue)
|
|
|
|
|
{
|
|
|
|
|
return dispatch_queue(display, queue, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-19 15:30:25 +03:00
|
|
|
/** Process incoming events
|
2012-10-12 17:28:57 +03:00
|
|
|
*
|
|
|
|
|
* \param display The display context object
|
2012-10-16 17:29:08 +03:00
|
|
|
* \return The number of dispatched events on success or -1 on failure
|
2012-10-12 17:28:57 +03:00
|
|
|
*
|
|
|
|
|
* Dispatch the display's main event queue.
|
|
|
|
|
*
|
2012-10-19 15:30:25 +03:00
|
|
|
* If the main event queue is empty, this function blocks until there are
|
|
|
|
|
* events to be read from the display fd. Events are read and queued on
|
|
|
|
|
* the appropriate event queues. Finally, events on the main event queue
|
|
|
|
|
* are dispatched.
|
|
|
|
|
*
|
|
|
|
|
* \note It is not possible to check if there are events on the main queue
|
|
|
|
|
* or not. For dispatching main queue events without blocking, see \ref
|
|
|
|
|
* wl_display_dispatch_pending().
|
|
|
|
|
*
|
|
|
|
|
* \note Calling this makes the current thread the main one.
|
|
|
|
|
*
|
|
|
|
|
* \sa wl_display_dispatch_pending(), wl_display_dispatch_queue()
|
2012-10-12 17:28:57 +03:00
|
|
|
*
|
|
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
WL_EXPORT int
|
|
|
|
|
wl_display_dispatch(struct wl_display *display)
|
|
|
|
|
{
|
|
|
|
|
display->display_thread = pthread_self();
|
2012-10-04 17:34:18 -04:00
|
|
|
|
2012-10-11 17:15:08 -04:00
|
|
|
return dispatch_queue(display, &display->queue, 1);
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-19 15:30:25 +03:00
|
|
|
/** Dispatch main queue events without reading from the display fd
|
|
|
|
|
*
|
|
|
|
|
* \param display The display context object
|
|
|
|
|
* \return The number of dispatched events or -1 on failure
|
|
|
|
|
*
|
|
|
|
|
* This function dispatches events on the main event queue. It does not
|
|
|
|
|
* attempt to read the display fd and simply returns zero if the main
|
|
|
|
|
* queue is empty, i.e., it doesn't block.
|
|
|
|
|
*
|
|
|
|
|
* This is necessary when a client's main loop wakes up on some fd other
|
|
|
|
|
* than the display fd (network socket, timer fd, etc) and calls \ref
|
|
|
|
|
* wl_display_dispatch_queue() from that callback. This may queue up
|
|
|
|
|
* events in the main queue while reading all data from the display fd.
|
|
|
|
|
* When the main thread returns to the main loop to block, the display fd
|
|
|
|
|
* no longer has data, causing a call to \em poll(2) (or similar
|
|
|
|
|
* functions) to block indefinitely, even though there are events ready
|
|
|
|
|
* to dispatch.
|
|
|
|
|
*
|
|
|
|
|
* To proper integrate the wayland display fd into a main loop, the
|
|
|
|
|
* client should always call \ref wl_display_dispatch_pending() and then
|
|
|
|
|
* \ref wl_display_flush() prior to going back to sleep. At that point,
|
|
|
|
|
* the fd typically doesn't have data so attempting I/O could block, but
|
|
|
|
|
* events queued up on the main queue should be dispatched.
|
|
|
|
|
*
|
|
|
|
|
* A real-world example is a main loop that wakes up on a timerfd (or a
|
|
|
|
|
* sound card fd becoming writable, for example in a video player), which
|
|
|
|
|
* then triggers GL rendering and eventually eglSwapBuffers().
|
|
|
|
|
* eglSwapBuffers() may call wl_display_dispatch_queue() if it didn't
|
|
|
|
|
* receive the frame event for the previous frame, and as such queue
|
|
|
|
|
* events in the main queue.
|
|
|
|
|
*
|
|
|
|
|
* \note Calling this makes the current thread the main one.
|
|
|
|
|
*
|
|
|
|
|
* \sa wl_display_dispatch(), wl_display_dispatch_queue(),
|
|
|
|
|
* wl_display_flush()
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
2012-10-11 17:15:08 -04:00
|
|
|
WL_EXPORT int
|
|
|
|
|
wl_display_dispatch_pending(struct wl_display *display)
|
|
|
|
|
{
|
|
|
|
|
display->display_thread = pthread_self();
|
|
|
|
|
|
|
|
|
|
return dispatch_queue(display, &display->queue, 0);
|
2008-10-07 10:10:36 -04:00
|
|
|
}
|
|
|
|
|
|
2012-11-14 13:58:31 -05:00
|
|
|
/** Retrieve the last error occurred on a display
|
2012-10-16 17:29:09 +03:00
|
|
|
*
|
|
|
|
|
* \param display The display context object
|
2012-11-14 13:58:31 -05:00
|
|
|
* \return The last error occurred on \c display or 0 if no error occurred
|
2012-10-17 21:26:09 +03:00
|
|
|
*
|
2012-11-14 13:58:31 -05:00
|
|
|
* Return the last error occurred on the display. This may be an error sent
|
2012-10-17 21:26:09 +03:00
|
|
|
* by the server or caused by the local client.
|
|
|
|
|
*
|
|
|
|
|
* \note Errors are \b fatal. If this function returns non-zero the display
|
|
|
|
|
* can no longer be used.
|
2012-10-16 17:29:09 +03:00
|
|
|
*
|
|
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
2012-10-11 23:37:42 +02:00
|
|
|
WL_EXPORT int
|
|
|
|
|
wl_display_get_error(struct wl_display *display)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
|
|
|
|
|
|
|
|
|
ret = display->last_error;
|
|
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&display->mutex);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-16 17:29:06 +03:00
|
|
|
/** Send all buffered request on the display to the server
|
|
|
|
|
*
|
|
|
|
|
* \param display The display context object
|
|
|
|
|
* \return The number of bytes send on success or -1 on failure
|
|
|
|
|
*
|
|
|
|
|
* Send all buffered data on the client side to the server. Clients
|
|
|
|
|
* should call this function before blocking. On success, the number
|
|
|
|
|
* of bytes sent to the server is returned. On failure, this
|
|
|
|
|
* function returns -1 and errno is set appropriately.
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_display
|
|
|
|
|
*/
|
2012-10-04 16:54:22 -04:00
|
|
|
WL_EXPORT int
|
2011-05-10 17:51:52 +01:00
|
|
|
wl_display_flush(struct wl_display *display)
|
|
|
|
|
{
|
2012-10-04 17:42:49 -04:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
pthread_mutex_lock(&display->mutex);
|
|
|
|
|
|
2012-10-11 23:37:53 +02:00
|
|
|
if (display->last_error) {
|
|
|
|
|
errno = display->last_error;
|
|
|
|
|
ret = -1;
|
|
|
|
|
} else {
|
|
|
|
|
ret = wl_connection_flush(display->connection);
|
|
|
|
|
if (ret < 0 && errno != EAGAIN)
|
|
|
|
|
display_fatal_error(display, errno);
|
|
|
|
|
}
|
2012-10-04 17:42:49 -04:00
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&display->mutex);
|
|
|
|
|
|
|
|
|
|
return ret;
|
2011-05-10 17:51:52 +01:00
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Set the user data associated with a proxy
|
|
|
|
|
*
|
|
|
|
|
* \param proxy The proxy object
|
|
|
|
|
* \param user_data The data to be associated with proxy
|
|
|
|
|
*
|
2012-10-15 17:53:23 +03:00
|
|
|
* Set the user data associated with \c proxy. When events for this
|
|
|
|
|
* proxy are received, \c user_data will be supplied to its listener.
|
2012-10-12 17:28:57 +03:00
|
|
|
*
|
|
|
|
|
* \memberof wl_proxy
|
|
|
|
|
*/
|
2009-09-18 09:49:21 -04:00
|
|
|
WL_EXPORT void
|
2010-08-17 21:23:10 -04:00
|
|
|
wl_proxy_set_user_data(struct wl_proxy *proxy, void *user_data)
|
2009-09-18 09:49:21 -04:00
|
|
|
{
|
2010-08-10 14:02:48 -04:00
|
|
|
proxy->user_data = user_data;
|
2009-09-18 09:49:21 -04:00
|
|
|
}
|
|
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Get the user data associated with a proxy
|
|
|
|
|
*
|
|
|
|
|
* \param proxy The proxy object
|
|
|
|
|
* \return The user data associated with proxy
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_proxy
|
|
|
|
|
*/
|
2009-09-18 09:49:21 -04:00
|
|
|
WL_EXPORT void *
|
2010-08-17 21:23:10 -04:00
|
|
|
wl_proxy_get_user_data(struct wl_proxy *proxy)
|
2009-09-18 09:49:21 -04:00
|
|
|
{
|
2010-08-10 14:02:48 -04:00
|
|
|
return proxy->user_data;
|
2009-09-18 09:49:21 -04:00
|
|
|
}
|
2012-04-27 11:31:07 -04:00
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Get the id of a proxy object
|
|
|
|
|
*
|
|
|
|
|
* \param proxy The proxy object
|
|
|
|
|
* \return The id the object associated with the proxy
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_proxy
|
|
|
|
|
*/
|
2012-04-27 11:31:07 -04:00
|
|
|
WL_EXPORT uint32_t
|
|
|
|
|
wl_proxy_get_id(struct wl_proxy *proxy)
|
|
|
|
|
{
|
|
|
|
|
return proxy->object.id;
|
|
|
|
|
}
|
2012-05-29 17:37:02 +02:00
|
|
|
|
2013-02-26 15:19:44 +02:00
|
|
|
/** Get the interface name (class) of a proxy object
|
|
|
|
|
*
|
|
|
|
|
* \param proxy The proxy object
|
|
|
|
|
* \return The interface name of the object associated with the proxy
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_proxy
|
|
|
|
|
*/
|
|
|
|
|
WL_EXPORT const char *
|
|
|
|
|
wl_proxy_get_class(struct wl_proxy *proxy)
|
|
|
|
|
{
|
|
|
|
|
return proxy->object.interface->name;
|
|
|
|
|
}
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
|
2012-10-12 17:28:57 +03:00
|
|
|
/** Assign a proxy to an event queue
|
|
|
|
|
*
|
|
|
|
|
* \param proxy The proxy object
|
|
|
|
|
* \param queue The event queue that will handle this proxy
|
|
|
|
|
*
|
2012-10-15 17:53:23 +03:00
|
|
|
* Assign proxy to event queue. Events coming from \c proxy will be
|
2012-10-12 17:28:57 +03:00
|
|
|
* queued in \c queue instead of the display's main queue.
|
|
|
|
|
*
|
|
|
|
|
* \sa wl_display_dispatch_queue()
|
|
|
|
|
*
|
|
|
|
|
* \memberof wl_proxy
|
|
|
|
|
*/
|
client: Add wl_event_queue for multi-thread dispatching
This introduces wl_event_queue, which is what will make multi-threaded
wayland clients possible and useful. The driving use case is that of a
GL rendering thread that renders and calls eglSwapBuffer independently of
a "main thread" that owns the wl_display and handles input events and
everything else. In general, the EGL and GL APIs have a threading model
that requires the wayland client library to be usable from several threads.
Finally, the current callback model gets into trouble even in a single
threaded scenario: if we have to block in eglSwapBuffers, we may end up
doing unrelated callbacks from within EGL.
The wl_event_queue mechanism lets the application (or middleware such as
EGL or toolkits) assign a proxy to an event queue. Only events from objects
associated with the queue will be put in the queue, and conversely,
events from objects associated with the queue will not be queue up anywhere
else. The wl_display struct has a built-in event queue, which is considered
the main and default event queue. New proxies are associated with the
same queue as the object that created them (either the object that a
request with a new-id argument was sent to or the object that sent an
event with a new-id argument). A proxy can be moved to a different event
queue by calling wl_proxy_set_queue().
A subsystem, such as EGL, will then create its own event queue and associate
the objects it expects to receive events from with that queue. If EGL
needs to block and wait for a certain event, it can keep dispatching event
from its queue until that events comes in. This wont call out to unrelated
code with an EGL lock held. Similarly, we don't risk the main thread
handling an event from an EGL object and then calling into EGL from a
different thread without the lock held.
2012-10-05 13:49:48 -04:00
|
|
|
WL_EXPORT void
|
|
|
|
|
wl_proxy_set_queue(struct wl_proxy *proxy, struct wl_event_queue *queue)
|
|
|
|
|
{
|
|
|
|
|
proxy->queue = queue;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-29 17:37:02 +02:00
|
|
|
WL_EXPORT void
|
|
|
|
|
wl_log_set_handler_client(wl_log_func_t handler)
|
|
|
|
|
{
|
|
|
|
|
wl_log_handler = handler;
|
|
|
|
|
}
|