async notifications need improvement

[fuchsnj]

Currently it seems like there are 2 ways to use async notifications.

1: blocking

let connection = Connection::connect(...);
let notification = connection.notifications().next_block().unwrap()

Using this method, it doesn't seem possible to do any queries on this connection while it is blocking (listen / unlisten query) so it is mostly useless except for a few use-cases.

2: polling

let connection =Connection::connect(...);
loop{//while app is running
   let result = connection.query(...);//do some query
   for notification in connection.notifications(){
      ... do something with notification
   }
}

This method only works if you are constantly sending queries on every connection listening for notifications, otherwise a connection will not receive the notification until the next query is sent (which isn't very async!) or a dummy query is sent (which kills performance!).

Method 2 (polling) would be somewhat acceptable if there was a method to retrieve async notifications without having to run a query. (It would check the input stream and process any messages from postgres, but not block if no data exists).

A best case scenario I think would be if you could register a background listener to a connection (it would probably have to be a thread running in the background until Rust has better non-blocking IO) where you give it the sender of a channel (https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html) and receive a message on the channel on each notification.

[sfackler]

There's also this method, which is disabled until timeouts are added back to libstd's io: https://github.com/sfackler/rust-postgres/blob/master/src/lib.rs#L290-L344.

I'm not totally sure how the proposed background listener would work. It'd have to be constantly listening on the socket for messages, which would then cause it to accidentally intercept non-notification messages. I guess the background thread could be the thing that does all the reading and then sends the non-notification messages over to the main connection through a channel, but that seems kind of weird and adds a fair amount of complication (have to worry about backpressure issues etc).

To me, the most straightforward way to handle this seems like having a separate thread that has its own connection and loops on next_block.

[fuchsnj]

If you have a separate thread looping on next_block, isn't the connection mutably borrowed, so another thread couldn't run a listen/unlisten query?

[sfackler]

Not if each thread has its own connection that it owns exclusively.