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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
