XEmacs versus Cygwin 3.3 (was Re: Another pipe-related problem?)

Ar an t-ochtú lá de mí na Nollaig, scríobh Henry S. Thompson: > [...] > #define STRIDE sizeof (STRIDE_TYPE) > > Ken/Aidan, is it possible that the last line interacts badly with some > (stale?) #ifdef code at lines 177 and 190 in sysdep.c [attached for > Ken's benefit] in a way that

XEmacs versus Cygwin 3.3 (was Re: Another pipe-related problem?)

Henry S. Thompson via Cygwin writes: > [XEmacs no longer works with Cygwin 3.3] > Ken Brown writes: > >> The main change was that we stopped using Win32 Overlapped I/O >> (https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-and-overlapped-input-and-output) >> and switched to using

Re: Another pipe-related problem?

On 11/10/2021 1:42 PM, Henry S. Thompson wrote: Ken Brown writes: The good news is that the bug doesn't seem to occur in XEmacs 21.4 (on 32-bit Cygwin). So one way to approach this would be to bisect the XEmacs git repo to find the commit that introduced the bug. You'd probably have to do the

Re: Another pipe-related problem?

Greetings, Andrey Repin via Cygwin! > Though I strongly require a virtual machine for such exercises. -require +recommend Sorry for confusion. -- With best regards, Andrey Repin Thursday, November 11, 2021 14:06:19 Sorry for my terrible english... -- Problem reports:

Re: Another pipe-related problem?

Greetings, Henry S. Thompson! >> ... >> The main change was that we stopped using Win32 Overlapped I/O >> (https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-and-overlapped-input-and-output) >> and switched to using the NT API. As a result, pipe I/O became much >> more

Re: Another pipe-related problem?

Ken Brown writes: > ... > The main change was that we stopped using Win32 Overlapped I/O > (https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-and-overlapped-input-and-output) > and switched to using the NT API. As a result, pipe I/O became much > more efficient. It wouldn't

Re: Another pipe-related problem?

On 11/10/2021 12:23 PM, Henry S. Thompson wrote: Ken Brown via Cygwin writes: On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote: Back to the drawing board. It finally occurred to me to stop looking for a bug in fhandler_pipe::raw_read and instead see if something is in fact repeatedly

Re: Another pipe-related problem?

Ken Brown via Cygwin writes: > On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote: >> Back to the drawing board. > > It finally occurred to me to stop looking for a bug in > fhandler_pipe::raw_read and instead see if something is in fact > repeatedly writing to the pipe, so that

Re: Another pipe-related problem?

On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote: Back to the drawing board. It finally occurred to me to stop looking for a bug in fhandler_pipe::raw_read and instead see if something is in fact repeatedly writing to the pipe, so that drain_signal_event_pipe never finishes. Putting a

Re: Another pipe-related problem?

Please pardon the interjection. I'm a hardware guy and any time a hardware process is in a state where it is waiting for a signal from another process, I put in a timeout mechanism. Shouldn't this be a normal practice for software as well? -- Problem reports:

Re: Another pipe-related problem?

On 11/9/2021 5:20 PM, Ken Brown via Cygwin wrote: On 11/9/2021 5:16 PM, Ken Brown via Cygwin wrote: On 11/9/2021 9:11 AM, Ken Brown via Cygwin wrote: On 11/9/2021 5:55 AM, Henry S. Thompson wrote: As you may know, the XEmacs situation is complicated.  The old source repo

Re: Another pipe-related problem?

On 11/9/2021 7:37 PM, Takashi Yano via Cygwin wrote: On Wed, 10 Nov 2021 09:16:13 +0900 Takashi Yano wrote: On Wed, 10 Nov 2021 08:48:22 +0900 Takashi Yano wrote: On Wed, 10 Nov 2021 08:29:32 +0900 Takashi Yano wrote: On Wed, 10 Nov 2021 08:22:45 +0900 Takashi Yano wrote: On Tue, 9 Nov 2021

Re: Another pipe-related problem?

On Wed, 10 Nov 2021 09:16:13 +0900 Takashi Yano wrote: > On Wed, 10 Nov 2021 08:48:22 +0900 > Takashi Yano wrote: > > On Wed, 10 Nov 2021 08:29:32 +0900 > > Takashi Yano wrote: > > > On Wed, 10 Nov 2021 08:22:45 +0900 > > > Takashi Yano wrote: > > > > On Tue, 9 Nov 2021 09:11:28 -0500 > > > > Ken

Re: Another pipe-related problem?

On Wed, 10 Nov 2021 08:48:22 +0900 Takashi Yano wrote: > On Wed, 10 Nov 2021 08:29:32 +0900 > Takashi Yano wrote: > > On Wed, 10 Nov 2021 08:22:45 +0900 > > Takashi Yano wrote: > > > On Tue, 9 Nov 2021 09:11:28 -0500 > > > Ken Brown wrote: > > > > I'll have to reproduce the hang myself in order to

Re: Another pipe-related problem?

On Wed, 10 Nov 2021 08:29:32 +0900 Takashi Yano wrote: > On Wed, 10 Nov 2021 08:22:45 +0900 > Takashi Yano wrote: > > On Tue, 9 Nov 2021 09:11:28 -0500 > > Ken Brown wrote: > > > I'll have to reproduce the hang myself in order to test this (or maybe > > > you could > > > test it), but I now have

Re: Another pipe-related problem?

On Wed, 10 Nov 2021 08:22:45 +0900 Takashi Yano wrote: > On Tue, 9 Nov 2021 09:11:28 -0500 > Ken Brown wrote: > > I'll have to reproduce the hang myself in order to test this (or maybe you > > could > > test it), but I now have a new guess: If the read call above keeps failing > > with > >

Re: Another pipe-related problem?

On Tue, 9 Nov 2021 09:11:28 -0500 Ken Brown wrote: > I'll have to reproduce the hang myself in order to test this (or maybe you > could > test it), but I now have a new guess: If the read call above keeps failing > with > EINTR, then we're in an infinite loop. This could happen because of the

Re: Another pipe-related problem?

On 11/9/2021 5:16 PM, Ken Brown via Cygwin wrote: On 11/9/2021 9:11 AM, Ken Brown via Cygwin wrote: On 11/9/2021 5:55 AM, Henry S. Thompson wrote: As you may know, the XEmacs situation is complicated.  The old source repo (bitbucket.org/xemacs) no longer exists.  There's a fork that's still

Re: Another pipe-related problem?

On 11/9/2021 9:11 AM, Ken Brown via Cygwin wrote: On 11/9/2021 5:55 AM, Henry S. Thompson wrote: As you may know, the XEmacs situation is complicated.  The old source repo (bitbucket.org/xemacs) no longer exists.  There's a fork that's still being maintained, but it's not widely publicised. 

Re: Another pipe-related problem?

[private reply -- it's not exactly a private repo, but it's really not ready for prime-time with users expecting to be able to raise issues etc.] Ken Brown writes: > ... > I was aware that the bitbucket repo didn't exist, because I tried to get the > sources there. But I didn't know about the

Re: Another pipe-related problem?

On 11/9/2021 5:55 AM, Henry S. Thompson wrote: Ken Brown via Cygwin writes: On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote: Running on Windows-10 21H1 With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs: .. #6 0x00018013ffcc in read (fd=3,

Re: Another pipe-related problem?

Ken Brown via Cygwin writes: > On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote: >> Running on Windows-10 21H1 >> >> With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs: >> >> .. >> #6 0x00018013ffcc in read (fd=3, ptr=0x0bc0, len=) >> at

Re: Another pipe-related problem?

On 11/8/2021 9:35 AM, Ken Brown via Cygwin wrote: On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote: Running on Windows-10 21H1 With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs: #0  0x7ffdf31cd474 in ntdll!ZwQueryTimer ()     from

Re: Another pipe-related problem?

On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote: Running on Windows-10 21H1 With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs: #0 0x7ffdf31cd474 in ntdll!ZwQueryTimer () from /c/Windows/SYSTEM32/ntdll.dll #1 0x0001800479fa in cygwait (object=,

Another pipe-related problem?

Running on Windows-10 21H1 With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs: #0 0x7ffdf31cd474 in ntdll!ZwQueryTimer () from /c/Windows/SYSTEM32/ntdll.dll #1 0x0001800479fa in cygwait (object=, timeout=0x09a0, timeout@entry=0x0, mask=mask@entry=5)