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

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 (view raw or flat)
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: cancel.patch
Description: application/octet-stream (17.2 KB)

Responses

pgsql-patches by date

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

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