Re: Windows buildfarm members vs. new async-notify isolation test

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Sun, Dec 8, 2019 at 10:27 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Doing it like this seems attractive to me because it gets rid of two
>> different failure modes: inability to create a new thread and inability
>> to create a new pipe handle. Now on the other hand, it means that
>> inability to complete the read/write transaction with a client right
>> away will delay processing of other signals. But we know that the
>> client is engaged in a CallNamedPipe operation, so how realistic is
>> that concern?

> Right, the client is engaged in a CallNamedPipe operation, but the
> current mechanism can allow multiple such clients and that might lead
> to faster processing of signals.

It would only matter if multiple processes signal the same backend at the
same time, which seems to me to be probably a very minority use-case.
For the normal case of one signal arriving at a time, what I'm suggesting
ought to be noticeably faster because of fewer kernel calls. Surely
creating a new pipe instance and a new thread are not free.

In any case, the main thing I'm on about here is getting rid of the
failure modes. The existing code does have a rather lame/buggy
workaround for the cant-create-new-pipe case. A possible answer for
cant-create-new-thread might be to go ahead and service the current
request locally in the long-lived signal thread. But that seems like
it's piling useless (and hard to test) complexity on top of useless
complexity.

> Ideally, we can run a couple of tests to see if there is any help in
> servicing the signals with this mechanism over proposed change on
> different Windows machines, but is it really worth the effort?

The failure modes I'm worried about are obviously pretty low-probability;
if they were not, we'd be getting field reports about it. So I'm not
sure how you can test your way to a conclusion about whether this is an
improvement. But we're not in the business of ignoring failure modes
just because they're low-probability. I'd argue that a kernel call
that's not there is a kernel call that cannot fail, and therefore ipso
facto an improvement.

regards, tom lane