Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] Asynchronous connect using libpq

From: eem21(at)cam(dot)ac(dot)uk
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: [INTERFACES] Asynchronous connect using libpq
Date: 1999-07-18 15:24:39
Message-ID: E115sh6-0003G3-00@red.csi.cam.ac.uk (view raw or flat)
Thread:
Lists: pgsql-interfaces
On 18 Jul, Tom Lane wrote:
> eem21(at)cam(dot)ac(dot)uk writes:
>> I need non-blocking versions of PQconnectdb and PQreset in libpq,
>> analogous to the asynchronous query processing functions (PQsendQuery
>> et al).
> 
> Gonna have to write them yourself, I'm afraid.  PQconnect is actually
> a rather long sequence, involving completing an authentication protocol
> with the server and then sending a few standard setup commands.
> See libpq/fe-connect.c.
> 
> PQreset just closes the connection and then invokes PQconnect.
> 
>> I am willing to write these, if no one else has time to do so, but would
>> appreciate some input before I get started.
> 
> For maintainability, there'd need to be just one copy of the setup code
> not two, so you'd want to do something similar to the way I implemented
> the async query processing: write the async code and then replace the
> synchronous routines with simple loops that call the async version.
> 
> Turning the bottom part of connectDB() plus PQsetenv() into a state
> machine would be a fairly straightforward way of making this happen.
> connectDB is nearly there already, you'd just need to move the loop
> up to its caller.

That all sounds fine.

> Probably the most serious problem you'd have to consider before diving
> into this is that on most platforms, both gethostbyname() and connect()
> can involve nontrivial delays, and I know of no portable way to replace
> them with asynchronous operations.  If you can live with a DNS lookup
> delay then you can probably live with the other delays, and if you can't
> then it's not clear you would have a workable solution when you got done
> anyway :-(.

I realised that some time after I sent my first message, and have been
thinking about it since.  The delay for gethostbyname is not
acceptable, and we are going to have to get around that problem
elsewhere in the application anyway.  Therefore, I was thinking that I
could arrange to pass an IP address into libpq.  This would eliminate
the host look-up, and we can worry about the portability of our own
software, leaving libpq free from such trouble.

With regards to the connect() problem, I was hoping that by setting the
socket to non-blocking mode before connecting (exactly as it is
currently done after the connect call) I could solve that problem.  The
behaviour of a non-blocking socket on connection is documented in my
glibc 2.0 docs, and is supposed to be portable to SVr4 and 4.4BSD.  I
hope to be able to avoid breaking systems that don't handle such a setup
appropriately, by continuing to handle the case that the connection is
completed on completion of the initial connect() call.  Of course, the
caveat there is that the function loses its non-blocking properties,
but at least nothing is broken.

I don't know anything about the behaviour of WinSock, but I should be
able simply not to break anything ;-)

Ewan Mellor.



In response to

pgsql-interfaces by date

Next:From: Tom LaneDate: 1999-07-18 15:48:34
Subject: Re: [INTERFACES] Asynchronous connect using libpq
Previous:From: Tom LaneDate: 1999-07-18 14:43:21
Subject: Re: [INTERFACES] Asynchronous connect using libpq

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group