[PATCH] Fix re-entrancy issues in wl_display_iterate().

[Hannu Lyytinen]

On Fri, 2012-04-13 at 11:49 +0300, Pekka Paalanen wrote:
> On Fri, 13 Apr 2012 01:08:29 -0700 (PDT)
> yan.wang at linux.intel.com wrote:
> > wl_display_iterate will be called in multiply threads? Normally, I think
> > it may be called in message loop thread.
> > Thanks.
> 
> It does not seem to be about threads or parallelism, but nested calls.
> wl_display_iterate() will dispatch events, therefore call your handler
> functions, and if a handler function happens to call
> wl_display_iterate(), you get screwed. This concerns only
> wl_display_iterate(WL_DISPLAY_READABLE) type of calls.
> 
> Hannu, I am not sure allowing this is actually sane. Can you clarify
> your case, why you need it?

Sorry, I cannot disclose full details (at least yet) because it appeared
during a customer project. But it was basically a synchronous call over
Wayland and we had to wait for the corresponding callback to be called.
In other words, we called wl_display_iterate() only as long as we had
not received the reply. And because we knew nothing can interfere or add
anything extra into connection queue (we had written some kind of
extension to weston compositor so we had control over what it does), it
was deemed safe. The wl_display_iterate() would just munch the "return
value". 

Then we had nested calls when the nested wl_display_iterate() caused
problems. Even though we were 100% sure our nested call cannot alter the
contents of the connection queue (in any other way than described
above), the outer wl_display_iterate() didn't realize something some
bytes were eaten from the queue and it tried to read past the end of the
queue. This is what the patch fixes.

So I would say nested wl_display_iterate() is OK as long as you really
know what you are doing. You are right it cannot be used carelessly.


-- 
Hannu Lyytinen
Senior Software Developer, Nomovok Ltd
email: hannu.lyytinen at nomovok.com