3.3.0: Possible regression in cygwin DLL (Win10); fixed in snapshot

[Takashi Yano]

On Thu, 11 Nov 2021 10:52:33 +0100
Corinna Vinschen wrote:
> On Nov 10 21:35, Corinna Vinschen wrote:
> > On Nov 10 22:30, Takashi Yano wrote:
> > > On Wed, 10 Nov 2021 11:34:25 +0100
> > > Corinna Vinschen wrote:
> > > > On Nov 10 17:30, Takashi Yano wrote:
> > > > > I tried to implement your idea, however, I noticed that
> > > > > NtQueryObject(ObjectNameInformation) call in
> > > > > get_query_hdl_per_process() is blocked while reading the
> > > > > pipe if FIPE_SYNCHRONOUS_IO_NONALERT is set and pipe is
> > > > > in blocking mode.
> > > > > 
> > > > > So I would like to propose alternative implementation with
> > > > > FILE_SYNCHRONOUS_IO_NONALERT being set. Please have a look
> > > > > at attached patch. With this patch, pipe itself in read side
> > > > > is always set to nonblocking mode and simulate the blocking
> > > > > behaviour in raw_read(). This can eliminate creating thread
> > > > > for reading as well as calling CancelSynchronousIo().
> > > > > 
> > > > > Note that setting FILE_SYNCHRONOUS_IO_NONALERT only for read
> > > > > pipe seems to be enough for C# programs.
> > > > > 
> > > > > What do you think of this implementation?
> > > > 
> > > > Can you push this to the topic/pipe branch for playing?  I updated
> > > > the branch to current master.
> > > 
> > > Thanks. I have just pushed the experimental patch to topic/pipe.
> > > Please try. If something wrong, please point it out.
> > 
> > Great, I'll have a look.  Ken, you're looking as well, right?
> 
> What I like with this approach is that it actually simplifies the code.
> 
> What I don't like much is that we are now running a busy loop, but the
> NtQueryObject hang is... disappointing, to say the least.  What about
> using another function like NtQueryInformationFile(FileNameInformation)?
> I bet this hangs, too, right?  

I have just confirmed that NtQueryInformationFile(FileNameInformation)
also hangs.

> Btw., while looking I was wondering if get_query_hdl_per_process and
> get_query_hdl_per_system could be replaced by a function utilizing
> NtQueryInformationFile(FileProcessIdsUsingFileInformation).  This
> supposedly returns all process ids of processes having an open handle to
> this file.  This could be quite a bit faster than the other two
> functions, ideally.  Per MSDN, FileProcessIdsUsingFileInformation
> exists since Vista.

Thanks for advice. get_query_hdl_per_* is called in the write side,
so only knows pipe handle of the write side. We would like to know
ProcessId which have pipe handle of the read side. Can we use
FileProcessIdsUsingFileInformation for this perpose?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>