Re: Win32 open items

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Win32 open items
Date: 2004-10-30 20:51:01
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE47605E@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

>>> 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

Attachment Content-Type Size
cancel.patch application/octet-stream 17.2 KB

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2004-10-30 21:13:38 WIP: shared dependencies
Previous Message Tom Lane 2004-10-30 19:58:52 Re: Win32 open items