Re: Win32 open items
От | Magnus Hagander |
---|---|
Тема | Re: Win32 open items |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE456A3A@algol.sollentuna.se обсуждение исходный текст |
Ответы |
Re: Win32 open items
Re: Win32 open items |
Список | 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 по дате отправления: