Re: Win32 open items - Mailing list pgsql-patches

From Magnus Hagander
Subject Re: Win32 open items
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE456A3A@algol.sollentuna.se
Whole thread Raw
Responses Re: Win32 open items  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Win32 open items  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
>> Here is an attempt at this. First patch contains the changes
>to libpq,
>> second patch contains changes to psql to use this API. Docs
>not updated
>> yet, pending approval of the general idea at least :)
>
>I think it would be better to dispense with the PQgetCancelError
>function and just make the signature of PQcancel be
>    int PQcancel(PGcancel *cancel, char *errbuf, int errbuflen);
>where errbuf would normally point to a local array in the calling
>function.
>
>As-is, PQcancel is itself not thread safe because it is scribbling
>on the PGcancel struct.  I thought the whole point of this exercise
>was to allow multiple threads to use the PGcancel struct; which seems
>to me to imply that it had better be read-only to PQcancel.

Um. Right. I somehow had it in my head that the 1 thread <-> 1 PGcancel
would always hold, in which case this would not be a problem. Now that
you put it like this, I have no idea why I made that assumption.
I'll get a new patch together using that syntax.


>We don't need the cancelConnLock if this is done properly (at least,
>assuming that storing a pointer is atomic, which seems reasonable).

Are you sure about this?
Per what docs I have, storing a pointer should always be atomic.
exchanging two pointers are not, which is why at least win32 provides a
specific function to do that (InterlockedExchangePointer).

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.
The fact that Thread B makes kernel socket calls for possibly remote
communications only makes the probability of Thread B actually being
switched out a whole lot higher.

Or are you seeing a scenario that prevents this from happening? (I guess
we could just ignore free:ing the memory, but that seems excessibly
ugly)


//Magnus

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Win32 open items
Next
From: Tom Lane
Date:
Subject: Re: Win32 open items