>>> We don't need the cancelConnLock if this is done properly (at least,
>>> assuming that storing a pointer is atomic, which seems reasonable).
>
>> Anyway, consider this scenario. Thread A is the mainloop
>thread, Thread
>> B is the thread that handles Ctrl-C. What if Thread B starts
>its run and
>> starts reading off the pointer. Before it's done, it's
>pre-empted, and
>> Thread A starts executing. Thread A does a free() on the
>memory pointed
>> to by the pointer. When control goes back to Thread B, it
>will definitly
>> die.
>
>Good point. Never mind that claim then ...
Ok, here we go with a new patch.
I started looking at docs, and reliased the PQrequestCancel() function
is documented under "async query processing". Is that really the correct
place? It has a mention that it's safe to use in signal handlers and can
thus be used by PQexec, but if you skip the async part because you're
not using async, you will never know you can cancel a query...
Not sure what to make of it. So here is a code-only patch. Most of the
docs would just be a copy of the old with a renamed patch anyway, but if
it should be restructured it should probably be done by someone who
knows a bit more about it.
//Magnus
