On Sun, Mar 24, 2013 at 01:49:05PM +0100, Uli Schlachter wrote:
> Hi again,
>
> On 22.03.2013 02:29, Kristian Høgsberg wrote:
> > On Thu, Mar 21, 2013 at 05:13:47PM +0100, Uli Schlachter wrote:
> >> On 21.03.2013 15:20, Kristian Høgsberg wrote:
> [...]
> >>> + * Calling wl_display_lock_fd() ensure
Hi again,
On 22.03.2013 02:29, Kristian Høgsberg wrote:
> On Thu, Mar 21, 2013 at 05:13:47PM +0100, Uli Schlachter wrote:
>> On 21.03.2013 15:20, Kristian Høgsberg wrote:
[...]
>>> + * Calling wl_display_lock_fd() ensures that no other thread will read
>>> + * the display fd. This means that no e
On Thu, Mar 21, 2013 at 05:13:47PM +0100, Uli Schlachter wrote:
> Hi,
>
> On 21.03.2013 15:20, Kristian Høgsberg wrote:
> > 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 loo
Hi,
On 21.03.2013 15:20, Kristian Høgsberg wrote:
> 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 wil
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
