This is a bit of a pickle and I'm unsure what's the best behavior here.
Since notifiers fire asynchronously via the event loop, we may end up
firing a notifier for a socket fd, but then reading/writing that socket
fd before ending up in the notifier callback.
In that situation, the socket is no longer in the same state as it was
when the event loop generated the notifier event.
This patch stops Socket from firing one hook in this situation but this
probably needs a global rethink.
With this change, Browser starts reliably in multi-process mode. :^)
RefPtr<Notifier> doesn't work quite like it appears to, since the notifier
is also a "child" of the socket, in Core::Object sense. Thus we have to both
remove it from the parent (socket) and drop the additional RefPtr<Notifier> for
it to actually go away.
A proper fix for this would be to untangle parent-child relashionship from
refcounting and inspectability.
This fixes use-after-close of client file descriptors in IPC servers.
The "ready to write" notifier we set up in generic socket connection is
really only meant to detect a successful connection. Once we have a TCP
connection, for example, it will fire on every event loop iteration.
This was causing IRC Client to max out the CPU by getting this no-op
notifier callback over and over.
Since this was only used by TLSv12, I changed that code to create its
own notifier instead. It might be possible to improve TLS performance
by only processing writes when actually needed, but I didn't look very
closely at that for this patch. :^)
