>>> 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
cancel.patch
Description: cancel.patch
---------------------------(end of broadcast)---------------------------
TIP 3: 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
