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 19:33:22
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE456A3A@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-10-30 19:58:52 Re: Win32 open items
Previous Message Tom Lane 2004-10-30 18:26:19 Re: Win32 open items