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

Amit Kapila <amit.kapila16@gmail.com> writes:
> On Sun, Dec 8, 2019 at 10:27 PM Tom Lane <tgl@sss.pgh.pa.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