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


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to