At Tue, 07 Jun 2016 15:38:04 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <24181.1465328284@sss.pgh.pa.us>
> Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> > At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <17504.1465225934@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