At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <17504.1465225934@sss.pgh.pa.us>
> Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> > At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <11515.1464961470@sss.pgh.pa.us>
> >> I think that this one:
> >>> If the target thread is allocating memory from the heap, the heap
> >>> lock will not be released.
> >> is potentially a hazard, which is why I made sure to use write_stderr
> >> later on in the console interrupt handler. 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 have to admit that I forgot about the possible malloc's, and
> > PQcancel() can be blocked from the same reason.
>
> 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.
> > If the issue to be settled here is the unwanted error messages,
> > we could set a flag to instruct write_msg to sit silent. Anyway
> > the workers should have been dead that time so discarding any
> > error messages don't matter.
> > What do you think about this?
>
> This is really ugly and I'm unconvinced that it fixes anything.
> write_msg is hardly the only place in a worker thread that might
> be doing malloc's; moreover, preventing workers from entering it
> after we start a shutdown does nothing for workers that might be
> in it already.
Yeah, it's ugly. But if we assume write() can be blocked, the
similar system calls used within PQcancel can be blocked, too. If
we don't assume so, using write instead of write_msg would do.
The problem I think is we don't have (or they don't offer?)
enough knowlegde about the inside of Windows APIs.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center