On Thu, Jan 14, 2016 at 10:56 AM, Andres Freund <and...@anarazel.de> wrote: > So, I'm wondering how we'd exactly use a hyptothetical > SetSocketToWaitOn, or SetSocketsToWaitOn (or whatever). I mean it can > make a fair bit of sense to sometimes wait on MyLatch/port->sock and > sometimes on MyLatch/fdw connections. The simple proposed code would > change the epoll set whenever switching between both, but with > SetSocketsToWaitOn you'd probably end up switching this much more often? > > One way to address that would be to create a 'latch wait' datastructure, > that'd then contain the epoll fd/win32 wait events/... That way you > could have one 'LatchWait' for latch + client socket and one for latch + > fdw sockets.
I see your point. As far as I can see, it's currently true that, right now, the only places where we wait for a socket are places where the socket will live for the lifetime of the backend, but I think we should regard it as likely that, in the future, we'll want to use it anywhere we want to wait for a socket to become ready. There are getting to be a lot of places where we need to unstick some loop whenever the process latch gets set, and it seems likely to me that needs will only continue to grow. So the API should probably contemplate that sort of need. I think your idea of a data structure the encapsulates a set of events for which to wait is probably a good one. WaitLatch doesn't seem like a great name. Maybe WaitEventSet, and then we can have WaitLatch(&latch) and WaitEvents(&eventset). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers