On Thu, 3 Nov 2005, Magnus Hagander wrote: > > > Sorry, I don't follow you here - what do you mean to do? Remove the > > > event completely so we can't wait on it? > > > > > > > I'd like to use the win32 provided recv(), send() functions > > instead of redirect them to pgwin32_recv()/pgwin32_send(), > > just like libpq does. If we do this, we will lose some > > functionalities, but I'd like to see the performance > > difference first. -- do you think that will be any difference? > > Doesn't work, really. It will no longer be possible to send a signal to > an idle backend. The idle backend will be blocking on recv(), that's how > it works. So unless we can get around that somehow, it's a non-starter I > think. Yeah, agreed. An alternative is set tiemout like 100 ms or so. When timeout happens, check the signals. But I guess you will be strongly against it. > > I doubt there will be much performance difference, as you hav eto hit > the kernel anyway (in the recv/send call). But that part is just a guess > :-) I know what you mean ... I will take a look -- if the patch (not including fix signaling problem), if doesn't change much, I will give it a try. Regards, Qingqing
