[GTK] Race condition when the socket event source is cancelled
authorcarlosgc@webkit.org <carlosgc@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 18 Mar 2014 15:02:51 +0000 (15:02 +0000)
committercarlosgc@webkit.org <carlosgc@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 18 Mar 2014 15:02:51 +0000 (15:02 +0000)
commitff6e123677b804587970e38fd63f85d33c5aa43b
tree0014bb5709dc5c6da680d2c1da75ff048d86f077
parentbae5e34bfaceb5960809f2d49026d3a52cf3d8ae
[GTK] Race condition when the socket event source is cancelled
https://bugs.webkit.org/show_bug.cgi?id=130395

Reviewed by Martin Robinson.

In some cases when the socket event source is cancelled the socket
event source callback is called with the condition of the previous
poll instead of 0. This can happen sometimes when the source is
cancelled from the socket event source callback. Once the socket
event source is cancelled, it's dispatched by glib without
polling, so the condition is never reset again and the callback is
called again and again with the previous condition. When the
condition is G_IO_IN, the source is re-scheduled entering into an
infinite loop. We should always check if the source has been
cancelled at the beginning of the callback to destroy the source
instead of relying on the condition being 0.

* Platform/gtk/WorkQueueGtk.cpp:
(WorkQueue::SocketEventSource::isCancelled):
(WorkQueue::SocketEventSource::eventCallback):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@165812 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit2/ChangeLog
Source/WebKit2/Platform/gtk/WorkQueueGtk.cpp