<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 10 September 2014 10:53, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 9 Sep 2014 15:39:35 +0200<br>
<span class="">Marek Chalupa <<a href="mailto:mchqwerty@gmail.com">mchqwerty@gmail.com</a>> wrote:<br>
<br>
> On 9 September 2014 13:10, Marek Chalupa <<a href="mailto:mchqwerty@gmail.com">mchqwerty@gmail.com</a>> wrote:<br>
><br>
> ><br>
> ><br>
> > On 4 September 2014 15:17, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>><br>
> > wrote:<br>
> ><br>
> >> On Fri, 29 Aug 2014 11:21:30 +0200<br>
> >> Marek Chalupa <<a href="mailto:mchqwerty@gmail.com">mchqwerty@gmail.com</a>> wrote:<br>
> >><br>
> >> > When wl_display_read_events() returns with errno == EAGAIN, we<br>
> >> > naturally try to call it again. But this next call results in<br>
> >> > deadlock.<br>
> >> ><br>
> >> > Signed-off-by: Marek Chalupa <<a href="mailto:mchqwerty@gmail.com">mchqwerty@gmail.com</a>><br>
> >> > ---<br>
> >> >  tests/display-test.c | 88<br>
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
> >> >  1 file changed, 88 insertions(+)<br>
<br>
</span><span class="">> >> But I see something else: wl_display_read_events() does not<br>
> >> decrement reader_count if it returns due to last_error. I think<br>
> >> that needs a fix to guarantee the reader_count is decremented, so<br>
> >> that the side-effects are consistent.<br>
> >><br>
> ><br>
> > Yes, we should fix this. There are cases that can cause a problem.<br>
> ><br>
><br>
> Actually, I can not make up any use-case where it is problem... do<br>
> you have any?<br>
<br>
</span>No, I just assumed it could be a problem, since it looks like it would<br>
violate an invariant (keeping the reader count consistent) by<br>
returning without decrementing. After all, prepare_read already<br>
succeeded, so it incremented the reader count.<br>
<br></blockquote><div><br></div><div>Yes, we can keep it consistent and decrement it - but after last_error is<br></div><div>set, all read attempts are suppressed, so it should not break anything, right?<br></div><div>But for the sake of consistency we can do it. After last_error is set, few<br></div><div>instructions are not harmful :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suppose the safest approach would be to maintain the guarantees we<br>
already had in 1.5.0.<br>
<br></blockquote><div><br></div><div>Hmm, yes. And if program uses poll (as probably most of them uses), then it should<br></div><div>not reach this problem.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Should a read_event failing due to last_error wake up all threads? It<br>
should be completely safe, but OTOH every site setting last_error<br>
already wakes up all threads and prevents anyone from sleeping in<br>
read_events again, right?<br>
<br></blockquote><div><br></div><div>Yes, all threads should be woken up by the function that sets last_error,<br></div><div>so this is safe. If we want have it completely consistent, we can<br></div><div>do cancel_read in this case, so that the reader_count is decremented<br>and if it drops to 0, then it will wake up sleeping threads (although there should not be any<br></div><div>- but it is not a problem for pthread broadcast)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div><div class="gmail_extra">Thanks,<br></div><div class="gmail_extra">Marek<br></div></div>