Re: Win32 open items

> > * Query cancel in psql
> >
> > I see two ways of doing this. One is to take the easy way
> out and just
> > add a console ctrl handler and let it do a standard query
> cancel. The
> > problem with this is that PQrequestCancel() is not
> thread-safe. Which
> > means we have a possible crash there, but only if we're either
> > PQfinish():ing the connection in the main thread, or if we're
> > accessing the error members (either reading or setting). If this is
> > acceptable, the fix for psql is really simple.
> >
> > If this is not acceptable, we have to do something along
> the line of
> > what's done in the backend to handle signals - we need to
> implement a
> > "signals aware" PQexec(). This function would have to call
> the async
> > query functions, and then wait for both these and an
> internal event to
> > look for cancel events. This is clearly the safest bet, but it's
> > definitly more work.
> >
> > Anybody have any other ideas that happen to be as simple as
> the first
> > optino but safer? Please ;-)
>
> I have an idea on this one. I think we need to put locking around
> access to psql/common.c::cancelConn so that we are sure the
> signal handler is not accessing it while it is being
> modified. We already have thread locking primitives for
> Win32 in libpq and we are sure the standard C functions are
> thread-safe on WIn32 because there are no special thread
> compile flags for Win32.
> We also might need to make
> cancelConn a copy of the PGconn structure rather than just a pointer.

It won't work unless you make it a copy, I think. Because you'd have to
lock the entire structure whenever you called PQexec() (since you don't
know when PQexec does things), and that's just the time when you'd need
to use it from the other thread...

As for making a copy, yes, that's the other optino I had, but completely
had lost when I wrote that mail. However, it cannot be done in just
pqsl, because psql doesn't see the contents of PGconn. We'd need at
least one new libpq function to create a duplicate PGconn. In order to
be safe, this should probably be a for-cancel-only-copy, so we shouldn't
copy the whole PGconn. But we could copy whatever fields are required to
cancel the query, which in turn would require a new cancelilng function
that accepted this limited structure.

Probably doable, but it requires API additions, I think.

> I can't think of how to simulate the longjump() currently
> used when cancelConn is NULL though.

Um. No need for that on win32, I think. When cancelConn is NULL (I am
now assuming we have solved the fact that cancelConn has to be a copy),
we can just do a "return" from the signal handler. The therad will then
happily end, and we're all fine. Or is it supposed to do something other
than just ignoring the cancel request if cancelconn is NULL?

//Magnus