At 09:38 AM 11-01-2001 -0800, Adam Haberlach wrote:
> We do something like this with listen/notify pairs. To syncronize
>two clients, we have them each listen for the other's token string,
>send a notify, and then block on select(), checking for incoming
>notifications. When they get the notification, they send a notify back
>to the other side to un-block it.
>
> If anything, it would be nice if there were a way to make a LISTEN
>block the connection on a specific event tag, which is essentially what
>we are doing in our interface library.
Actually what you are talking about is almost an inverse of this locking
thing. One is stop until it's ok to go. The other is stop if it's not ok to
go.
You're looking for a WAIT for "notification" feature :).
I actually was looking for this too, and I thought I was the only one
interested in this. Wow a 100% increase in interest ;).
I'm also trying to see how this can be done. It looks a lot easier to do
than the getlock feature. But I can't figure out what to select/wait/snooze
on, when the routine is in the inside looking about (async.c:
Async_Wait(char *relname) yeah oxymoronic I know). Rather than outside
looking in (in which case it's select PQsocket or something like that).
Would like to use as little CPU as possible when waiting - think of
postgresql on battery powered wearable "servers" + wireless LAN.
Cheerio,
Link.