[Webkit-unassigned] [Bug 141508] [SOUP] Synchronous XMLHttpRequests can time out when we reach the max connections limit

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=141508

--- Comment #3 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #2)
> (In reply to comment #1)
> > might be able to fix it by running the inner loop until you get
> > SoupSession::request-unqueued rather than just waiting for the message to
> > finish?
> 
> Yes, I thought about a similar solution but using SoupMessage::finished, and
> then I realized that it's unqueued right after SoupMessage::finished. I
> didn't see the request-unqueued signal. That Would still require changes in
> libsoup, though, to drop idle connections when limits are changed.

The problem is that the queue is not kicked when a message loaded from the cache switches to FINISHING state, so when using the nested main loop, since no other requests are processed (because of the different main context), the ::unqueue signal is never emitted and the main loop doesn't finish. I guess we should fix that in libsoup, but even fixing that would produce inconsistencies between resources loaded from the network and from the cache, because cached resources switch to FINISHING too early, so the message can be unqueued before we have finished reading the data stream, and the main loop could finish too early. 

The thing is that it doesn't seem to be possible to fix this without doing any change in libsoup, so I think a specific solution (something like the message flag I proposed) would work better, and it will be more reliable. This approach of increasing the limits and decreasing them after words looks very weak to me (and a bit hacky, TBH)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150216/1e0e2d43/attachment-0002.html>