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