Dieterbe/uzbl — pull request #117 by mathstuf (2013-06-18 05:01:05+00:00)
Title: dev/threaded-uzbl

Built on top of my next branch (which contains basically all of my other branches and is what I run day-to-day), this is a threaded uzbl implementation. The big feature: the EM can now answer synchronous requests (such as request_handler). This allows the EM to be a one-stop shop for plugins such as AdBlock and HTTPS-Everywhere (I have HTTPS-Everywhere working here; AdBlock needs some more work). This pull request was made with a build from this branch.

Basically, a thread is created which runs its own glib event loop. This is the loop which gets all of the I/O requests from the socket, FIFO, and stdin. This thread separates out replies to requests from the stream, puts them into a GPtrArray and broadcasts the fact on a GCond. Everything else goes into a GAsyncQueue. The other thread runs as uzbl normally has except that there is now a GSource feeding off of the other end of the GAsyncQueue and tries to run anything it gets. In the "request" command, it sends off a REQUEST-$cookie message to the --connect-socket sockets and then blocks, waiting for a reply with the same $cookie. Once it has received its reply, it moves along.

Some caveats about the implementation:

* If the EM deigns to not reply to uzbl-core, uzbl-core will hang. A timeout should be used to basically accept "no response" for the request. In addition, bogus replies will just sit in the reply buffer forever. This should be cleaned up every now and then. This was originally coded up with the idea of making uzbl fully threaded, but so far GTK and pango have said "no" pretty strongly, so maybe just waiting for a single reply rather than with a buffer of them would be enough.
* The cookie is generated by a very nasty hack. mkstemp is abused to get a 6-character cookie which is guaranteed to not be the same as an existing one for the instance and not really guessable.