Hi Knut, On Feb 25 01:51, knut st. osmundsen via Cygwin wrote: > Hi, > > I've been hunting an issue for some days now, where a non-cygwin program > using microsoft's UCRT sometimes end up with a sticky error on stdout when > running under cygwin perl with a pipe capturing stdout and stderr. When the > problem triggers, the pipe buffer appears to be full and it really looks > like it's hitting the errno=ENOSPC/doserrno=0 situation at the tail end of > _write_nolock() in ucrt/lowio/write.cpp. > > I *think* the issue is that the write end of the pipe isn't configured to be > synchronous. In winsup/cygwin/fhandler/pipe.cc, the nt_create() function > sets FILE_SYNCHRONOUS_IO_NONALERT when creating the _read_ end of the pipe > using NtCreateNamedPipeFile, citing some C# program compatibility need. > But, the call to NtOpenFile below that opens the _write_ end of the pipe > doesn't set it. It does set the SYNCHRONIZE access right, but doesn't set > the FILE_SYNCHRONOUS_IO_NONALERT flag (last parameter, is zero). This is > akin to calling CreateFile with FILE_FLAG_OVERLAPPED, if I understand it > correctly.
We can't make the write side of the pipe synchronous easily, because this means a pretty big rewrite of the current code. Right now, if we'd add the FILE_SYNCHRONOUS_IO_NONALERT, you couldn't interrupt NtWriteFile with a signal. We can add such a change to the TODO list for 3.7, using NtWriteFile in a thread or something like that. However, maybe there's a chance we can fix this for 3.6, if you would be able to create simple testcase in plain C, reproducing your issue, and the actual problem is not the FILE_SYNCHRONOUS_IO_NONALERT. > Also, in the error path of the NtOpenFile call, GetLastError() is used > instead of __seterrno_from_nt_status() or RtlNtStatusToDosError(). Thanks, I'll definitely fix that for 3.6. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
