sofar/buxton — pull request #59 by ikeydoherty (2014-01-31 13:59:16+00:00)
Title: Yesterday revisited

Took me a while to figure out why it was broken again.
Long story short, your poll method kinda breaks this. For it to operate asynchronously, there should be minimal blocking. In glibs own event loop, it will check the revents on each registered file descriptor.
In our case, we're only interested in G_IO_IN G_IO_PRI and G_IO_HUP.

Buxtons handle message method will block until data is available, or isn't dealt with, etc. So we *must* check the socket didn't actually terminate (G_IO_HUP) before trying to dispatch again to buxton. Otherwise Bad Things Happen, we shoulda closed it our end.

As a mild consequence of replacing the poll method, when you now close bt-daemon with bxt_gtk_client running, it completely hangs and blocks the socket, till it then segfaults from a broken pipe (due to the poll method being employed internally). Also, when starting, bxt_gtk_client will hang when trying to get a non-existent key, which wasn't the case yesterday.

Trying to fix it my end, but we need to agree on the best approach here. I've pushed several now reverted/omitted fixes, lets figure out the best approach :) (Didn't realise my hashmap notification fix hadn't got in till a few days ago, which kept notifications broken)