Re: Lock on arbitrary string feature
От | Lincoln Yeoh |
---|---|
Тема | Re: Lock on arbitrary string feature |
Дата | |
Msg-id | 3.0.5.32.20010112110840.00847100@192.228.128.13 обсуждение исходный текст |
Ответ на | Re: Lock on arbitrary string feature (Adam Haberlach <adam@newsnipple.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: