Hi,
On 12.04.2013 22:27, Kristian Høgsberg wrote:
> On Thu, Apr 11, 2013 at 09:53:58AM +0200, Uli Schlachter wrote:
>> On 10.04.2013 23:55, Kristian Høgsberg wrote:
>> [...]
>>> +WL_EXPORT int
>>> +wl_display_acquire_fd(struct wl_display *display)
>>> +{
>>> + char c = 0;
>>> +
>>> + pthread_m
On Thu, Apr 11, 2013 at 09:53:58AM +0200, Uli Schlachter wrote:
> On 10.04.2013 23:55, Kristian Høgsberg wrote:
> [...]
> >+WL_EXPORT int
> >+wl_display_acquire_fd(struct wl_display *display)
> >+{
> >+char c = 0;
> >+
> >+pthread_mutex_lock(&display->mutex);
> >+
> >+if (display->reade
On 10.04.2013 23:55, Kristian Høgsberg wrote:
[...]
+WL_EXPORT int
+wl_display_acquire_fd(struct wl_display *display)
+{
+ char c = 0;
+
+ pthread_mutex_lock(&display->mutex);
+
+ if (display->reader_state == LOCKED_READER &&
+ !pthread_equal(display->reader, pthread_s
Kristian Høgsberg wrote:
This patch introduces new API to solve both problems. We add
int wl_display_acquire_fd(struct wl_display *display);
I'm a little confused, some sample source code showing where the acquire
call goes would help. My guess is each thread should do this:
The current thread model assumes that the application or toolkit will have
a thread that either polls the display fd and dispatches events or just
dispatches in a loop. Only the main thread will read from the fd while
all other threads will block on a pthread condition and expect the main
thread t
On Wed, Apr 10, 2013 at 2:29 PM, Uli Schlachter wrote:
> On 10.04.2013 17:16, Kristian Høgsberg wrote:
> [...]
>> +WL_EXPORT int
>> +wl_display_acquire_fd(struct wl_display *display)
>> +{
>> + char c = 0;
>> + int old_state;
>> +
>> + pthread_mutex_lock(&display->mutex);
>> +
>> +
On 10.04.2013 17:16, Kristian Høgsberg wrote:
[...]
> +WL_EXPORT int
> +wl_display_acquire_fd(struct wl_display *display)
> +{
> + char c = 0;
> + int old_state;
> +
> + pthread_mutex_lock(&display->mutex);
> +
> + if (display->reader_state == LOCKED_READER &&
> + !pthread_
Hi Kristian,
Your patch calls like 3 times "pthread_cond_wait(..)", shouldn't each of
these calls be in a loop?
>From a book on pthreads:
"You should always wait for a condition variable in a loop, to protect
against errors,
multiprocessor races, and spurious wakeups."
Kind Regards
_
Can wl_display_acquire_fd be merged into wl_display_dispatch_pending()?
It looks like you never want to call one without the other, and it also
appears that wl_display_dispatch releases it so this would be symmetric.
On 04/10/2013 08:16 AM, Kristian Høgsberg wrote:
wl_display_dispatch
The current thread model assumes that the application or toolkit will have
a thread that either polls the display fd and dispatches events or just
dispatches in a loop. Only the main thread will read from the fd while
all other threads will block on a pthread condition and expect the main
thread t
On Mon, Mar 25, 2013 at 09:42:11PM +0100, Uli Schlachter wrote:
> On 25.03.2013 21:33, Thiago Macieira wrote:
> > On segunda-feira, 25 de março de 2013 19.49.32, Uli Schlachter wrote:
> >> So wl_display_acquire_fd() would do:
> >>
> >> if (old_state == VOLUNTEER_READER) {
> >> write(dis
On Mon, Mar 25, 2013 at 01:24:53PM -0700, Thiago Macieira wrote:
> On segunda-feira, 25 de março de 2013 13.42.31, Kristian Høgsberg wrote:
> > which returns the display fd and blocks any thread trying to read from
> > the fd. Calling wl_display_dispatch() will read events, release the fd
> > and
On 25.03.2013 21:33, Thiago Macieira wrote:
> On segunda-feira, 25 de março de 2013 19.49.32, Uli Schlachter wrote:
>> So wl_display_acquire_fd() would do:
>>
>> if (old_state == VOLUNTEER_READER) {
>> write(display->reader_pipe[1], &c, 1);
>> pthread_cond_wait(&display->pipe_co
On segunda-feira, 25 de março de 2013 19.49.32, Uli Schlachter wrote:
> So wl_display_acquire_fd() would do:
>
> if (old_state == VOLUNTEER_READER) {
> write(display->reader_pipe[1], &c, 1);
> pthread_cond_wait(&display->pipe_cond, &display->mutex);
> read(display->reade
On segunda-feira, 25 de março de 2013 13.42.31, Kristian Høgsberg wrote:
> which returns the display fd and blocks any thread trying to read from
> the fd. Calling wl_display_dispatch() will read events, release the fd
> and the dispatch events. Alternatively, if after acquiring and polling
> th
On 25.03.2013 18:42, Kristian Høgsberg wrote:
[...]
> @@ -847,45 +973,105 @@ dispatch_event(struct wl_display *display, struct
> wl_event_queue *queue)
> }
>
> static int
> -dispatch_queue(struct wl_display *display,
> -struct wl_event_queue *queue, int block)
> +read_events(struct
The current thread model assumes that the application or toolkit will have
a thread that either polls the display fd and dispatches events or just
dispatches in a loop. Only the main thread will read from the fd while
all other threads will block on a pthread condition and expect the main
thread t
17 matches
Mail list logo
