On Thu, Mar 16, 2006 at 03:14:03PM -0500, Ernie Coskrey wrote:
>>On Wed, Mar 01, 2006 at 01:01:46PM -0500, Ernie Coskrey wrote:
>Here's a description of a second hang condition we were encountering,
>along
>with a patch for it.
>
>
>The application (pdksh in this case) doe
>On Wed, Mar 01, 2006 at 01:01:46PM -0500, Ernie Coskrey wrote:
Here's a description of a second hang condition we were encountering, along
with a patch for it.
The application (pdksh in this case) does a read on a pipe, which
eventually
calls pipe.cc fhandler_pipe:
On Wed, Mar 01, 2006 at 01:01:46PM -0500, Ernie Coskrey wrote:
>>>Here's a description of a second hang condition we were encountering, along
>>>with a patch for it.
>>>
>>>
>>>The application (pdksh in this case) does a read on a pipe, which eventually
>>>calls pipe.cc fhandler_pipe::read in Thr
>>Here's a description of a second hang condition we were encountering, along
>>with a patch for it.
>>
>>
>>The application (pdksh in this case) does a read on a pipe, which eventually
>>calls pipe.cc fhandler_pipe::read in Thread 1. This creates a new cygthread
>>with "read_pipe()" as the fun
On Wed, Mar 01, 2006 at 10:47:59AM -0500, Paul Clements wrote:
>Christopher Faylor wrote:
>
>>It's also in the latest snapshot: http://cygwin.com/snapshots/
>
>I got the latest cygwin dll snapshot (20060227) a few days ago and I've
>been stress testing ksh with this new dll since.
>
>The good new
Christopher Faylor wrote:
It's also in the latest snapshot: http://cygwin.com/snapshots/
I got the latest cygwin dll snapshot (20060227) a few days ago and I've
been stress testing ksh with this new dll since.
The good news is that the hang issues (signal related) that I was seeing
appear
On Mon, Feb 27, 2006 at 12:15:08PM -0500, Paul Clements wrote:
>Christopher Faylor wrote:
>>Attaching gdb to the running process shows another problem. I'll check
>>in a fix for this, too.
>
>Where can I find this patch? Could you post it or is there somewhere I
>should go to find it? I have a fe
Christopher Faylor wrote:
On Fri, Feb 24, 2006 at 03:22:05PM -0500, Paul Clements wrote:
OK, I think I see what is happening now:
set_signal_mask() does indeed call sig_dispatch_pending() to do a flush
when the signal mask changes. However, when the sigq is empty,
sig_dispatch_pending() ju
On Fri, Feb 24, 2006 at 03:22:05PM -0500, Paul Clements wrote:
>On Thu, Feb 23, 2006 at 04:40:33PM -0500, Christopher Faylor wrote:
>>Actually, I spoke too soon. I don't understand your analysis. You
>>make this statement:
>
>>>However, if the queueing of the blocked signal happens right after th
On Thu, Feb 23, 2006 at 04:40:33PM -0500, Christopher Faylor wrote:
> Actually, I spoke too soon. I don't understand your analysis.
> You make this statement:
>>However, if the queueing of the blocked signal happens right after the
>>signal mask change, then we miss the signal.
> but I don't u
On Thu, Feb 23, 2006 at 04:35:12PM -0500, Ernie Coskrey wrote:
>Here's a description of a second hang condition we were encountering, along
>with a patch for it.
>
>
>The application (pdksh in this case) does a read on a pipe, which eventually
>calls pipe.cc fhandler_pipe::read in Thread 1. This
On Thu, Feb 23, 2006 at 04:40:33PM -0500, Christopher Faylor wrote:
>On Thu, Feb 23, 2006 at 04:33:45PM -0500, Ernie Coskrey wrote:
>>There are two hang conditions that we've identified and have developed fixes
>>for. This is a description of the first of the two along with a patch; I'll
>>follo
On Thu, Feb 23, 2006 at 04:33:45PM -0500, Ernie Coskrey wrote:
>There are two hang conditions that we've identified and have developed fixes
>for. This is a description of the first of the two along with a patch; I'll
>follow up with a description and patch for the second.
>
>
>If a signal can't
case WAIT_TIMEOUT:
+ if(!i && __name)
+ i--;
break;
default:
if (!exiting)
> -Original Message-
> From: Ernie Coskrey
> Sent: Friday, February 10, 2006 1:31 PM
> To: Ernie Coskrey; 'cygwi
// it to the sigq) -- flush sigq to be sure
}
}
- if (sig == SIGCHLD)
- clearwait = true;
}
break;
}
> -Original Message-
> From: Ernie Coskrey
> Sent: Friday, February 10, 2006 1:31 PM
> To: E
We've been able to narrow this down some more. The shell gets hung in
sigsuspend(), waiting for SIGCHLD. We've verified that the process that's
executed as part of the command substitution does complete, and returns EOF,
and the shell (we're testing with pdksh) goes into sigsuspend and never c
16 matches
Mail list logo
