At Tue, 07 Jun 2016 15:38:04 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in <24181.1465328...@sss.pgh.pa.us> > Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes: > > At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in > > <17504.1465225...@sss.pgh.pa.us> > >> Uh, what? PQcancel is very carefully coded so that it's safe to use > >> in a signal handler. If it's doing mallocs someplace, that would be > >> surprising. > > > PQcancel is disigned to run in a signal handler on *Linux*, but > > the discussion here is that the equivalent of send/recv and the > > similars on Windows can be blocked by the TerminateThread'ed > > thread via heap lock. > > What's your evidence for that? I'd expect those to be kernel calls, > or whatever the equivalent concept is on Windows. If they are not, > and in particular if they do malloc's, I think we have got problems > in many other contexts besides parallel dump.
Well, I found that I misunderstood your following sentence. > Your original suggestion to use write_msg would end up going > through fprintf, which might well use malloc internally. (It's > possible that Windows' version of write() could too, I suppose, > but that's probably as low-level as we are going to get.) I took the sentence enclosed by parentheses as that write() or other syscalls may blocked by heap-lock on Windows. But it should mean that "We have no way than to regard Windows' version of write() as a kernel call, that is, heap-lock safe". It seems quite natural and I totally agree to the judgment. Consequently, I agree to just use write(), not write_msg() and consider the combination of PQcancel and TerminateThread safe on Windows. Sorry for my confusion. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
