Re: Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 13:00:09 -0500, Tom Lane wrote:
> : More generally, it seems clear to me that Microsoft's code is designed
> : around the assumption that an event object remains attached to a socket
> : for the lifetime of the socket. This business of transiently associating
> : event objects with sockets looks quite inefficient and is evidently
> : triggering a lot of unpleasant corner-case behaviors. I wonder whether we
> : should not try to make "pgsocket" encapsulate a socket and an associated
> : event object as a single entity on Windows. (Such a struct would be a
> : good place to keep a per-socket noblock flag, too.) I'm not going to
> : tackle that myself though.
>
> which I think is the same as what you're suggesting.

Pretty similar, yes. I think we're going to additionally need a 'pending
events' flag or something to store edge triggered
status. E.g. 'writable' which'd only be cleared by EWOULDBLOCK being
returned by send, and 'closed' which is never cleared.

I guess it'd make sense to do this for all platforms; so most code can
just do pg_send/recv/... and the platform differences live in
pgsock_win/posix or somesuch.

I'm inclined to fix this for 9.5 with something like the select() hack I
posted upthread, and then revamp this in 9.6. I don't want to push a
relatively large API overhaul into 9.5 at this point.

Because of the recent thread about WL_POSTMASTER_DEATH scaling badly I'm
also wondering if we should change the latch API to make
OwnLatch/InitLatch have a fixed association with the socket that can be
waited on. My testing shows that e.g. linux' epoll is noticeably faster,
even measurably so in the single threaded case or without
WL_POSTMASTER_DEATH, because it requires less locking on the kernel side
than setting up poll/select datastructures in the kernel everytime we're
blocking. Afaics there are no uses of latches where we'd want to use
different sockets.