At 05:06 PM 8/31/2003 -0400, you wrote:
>On Sun, Aug 31, 2003 at 04:48:10PM -0400, Pierre A. Humblet wrote:
>>Sorry I misunderstood. Exactly where did you add a Sleep?
>
>In sig_dispatch_pending after the sigframe.
sig_dispatch_pending wasn't meant for that (unlikely when no
Sleep) case.
During
On Sun, Aug 31, 2003 at 04:48:10PM -0400, Pierre A. Humblet wrote:
>Sorry I misunderstood. Exactly where did you add a Sleep?
In sig_dispatch_pending after the sigframe.
cgf
At 04:21 PM 8/31/2003 -0400, you wrote:
>>>Ok. I see what you mean but the old code was not actually right either.
>>>I wrote a test case (enclosed) which sent a signal to a process running
>>>a modified version of cygwin1.dll after the call to sigframe
>>>("guaranteed" with the judicious use of S
On Sun, Aug 31, 2003 at 04:11:47PM -0400, Pierre A. Humblet wrote:
>At 02:39 PM 8/31/2003 -0400, you wrote:
>>On Sun, Aug 31, 2003 at 11:23:52AM -0400, Pierre A. Humblet wrote:
>>>thanks for your quick response to the ftp crash.
>>
>>It would have been much quicker if I'd clued into the fact that a
At 02:39 PM 8/31/2003 -0400, you wrote:
>On Sun, Aug 31, 2003 at 11:23:52AM -0400, Pierre A. Humblet wrote:
>>thanks for your quick response to the ftp crash.
>
>It would have been much quicker if I'd clued into the fact that an
>address like a0dc018 != a0dc01c. It took my 127 attempts at running
On Sun, Aug 31, 2003 at 11:23:52AM -0400, Pierre A. Humblet wrote:
>thanks for your quick response to the ftp crash.
It would have been much quicker if I'd clued into the fact that an
address like a0dc018 != a0dc01c. It took my 127 attempts at running ftp
to finally see what was going on.
I can'
[EMAIL PROTECTED] wrote:
On Fri, Aug 29, 2003 at 11:54:25AM -0400, Christopher Faylor wrote:
In any event, I have just found an interesting paper by Ulrich Drepper
http://people.redhat.com/drepper/posix-signal-model.xml
To supplement this, I'd also suggest having a look at the detailed
comment
Hi Chris,
thanks for your quick response to the ftp crash.
At 04:32 PM 8/30/2003 -0400, you wrote:
>retaddr_on_stack is not always going to be identical to esp + 36 no
>matter where it comes from. I modified my test program to tickle the
>previous problem. I've included it below. You can short
On Sat, Aug 30, 2003 at 03:22:07PM -0400, Pierre A. Humblet wrote:
>At 11:55 AM 8/29/2003 -0400, you wrote:
>>On Fri, Aug 29, 2003 at 10:19:22AM -0400, Pierre A. Humblet wrote:
>>>Christopher Faylor wrote:
I was heartened to see that zsh did not crash when I sicc'ed this
program on it -- un
At 11:55 AM 8/29/2003 -0400, you wrote:
>On Fri, Aug 29, 2003 at 10:19:22AM -0400, Pierre A. Humblet wrote:
>>Christopher Faylor wrote:
>>>I was heartened to see that zsh did not crash when I sicc'ed this
>>>program on it -- until I tried to type something at the zsh prompt and
>>>saw that it was h
On Fri, Aug 29, 2003 at 11:54:25AM -0400, Christopher Faylor wrote:
>In any event, I have just found an interesting paper by Ulrich Drepper
http://people.redhat.com/drepper/posix-signal-model.xml
cgf
On Fri, Aug 29, 2003 at 10:19:22AM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>>I was heartened to see that zsh did not crash when I sicc'ed this
>>program on it -- until I tried to type something at the zsh prompt and
>>saw that it was hung. The reason was that the recursive signa
On Fri, Aug 29, 2003 at 10:18:17AM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>>Do you think that an occasional loop through the signal handler is
>>slowing things down that much? Do you think that sig_dispatch_pending
>>gets called a lot with all pending signals blocked? Are you
Christopher Faylor wrote:
>
> I was heartened to see that zsh did not crash when I sicc'ed this
> program on it -- until I tried to type something at the zsh prompt and
> saw that it was hung. The reason was that the recursive signal call
> stuff was still not right. We were restoring the return
Christopher Faylor wrote:
> >I was planning to also eventually propose patches for the following,
> >but it's more efficient to tell Chris while he is working on the code
> >and before I forget:
> >1) sigcatch_nosync could be an event instead of a semaphore. This
> > doesn't affect the logic an
On Thu, Aug 28, 2003 at 11:12:56PM -0400, Christopher Faylor wrote:
> So, I ended up checking in the change to use events and am building
> a snapshot now. With luck, I've solved Corinna's problems and maybe
> I can even release 1.5.3 this weekend.
I tried it and it actually seem to solve the pro
On Thu, Aug 28, 2003 at 09:19:26PM -0400, Christopher Faylor wrote:
>On Thu, Aug 28, 2003 at 08:53:39PM -0400, Pierre A. Humblet wrote:
>>I was planning to also eventually propose patches for the following,
>>but it's more efficient to tell Chris while he is working on the code
>>and before I forg
On Thu, Aug 28, 2003 at 08:53:39PM -0400, Pierre A. Humblet wrote:
>At 02:09 PM 8/20/2003 -0400, you wrote:
>>On Wed, Aug 20, 2003 at 01:48:50PM -0400, Pierre A. Humblet wrote:
>>>Christopher Faylor wrote:
>If you do something like:
>
>foo()
>{
> sigframe thisframe;
> si
At 02:09 PM 8/20/2003 -0400, you wrote:
>On Wed, Aug 20, 2003 at 01:48:50PM -0400, Pierre A. Humblet wrote:
>>Christopher Faylor wrote:
If you do something like:
foo()
{
sigframe thisframe;
sig_dispatch_pending ();
}
then the signal dispatch will happen w
Christopher Faylor wrote:
>
> >While looking at the code, I got worried by interrupt_setup(). As soon
> >as sigsave.sig = sig; is executed, the sigsave can be picked up by a
> >terminating handler. Thus shouldn't sigsave.sig = sig; be the last
> >statement in interrupt_setup() to avoid a race c
On Wed, Aug 20, 2003 at 01:48:50PM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>>>If you do something like:
>>>
>>>foo()
>>>{
>>> sigframe thisframe;
>>> sig_dispatch_pending ();
>>>}
>>>
>>>then the signal dispatch will happen when foo returns, not when
>>>sig_dispatch_pending r
Christopher Faylor wrote:
>>If you do something like:
>>
>>foo()
>>{
>> sigframe thisframe;
>> sig_dispatch_pending ();
>>}
>>
>>then the signal dispatch will happen when foo returns, not when
>>sig_dispatch_pending returns. The goal is that, in most cases, the
>>function closest to the user s
On Tue, Aug 19, 2003 at 11:31:32PM -0400, Christopher Faylor wrote:
>If you do something like:
>
>foo()
>{
> sigframe thisframe;
> sig_dispatch_pending ();
>}
>
>then the signal dispatch will happen when foo returns, not when
>sig_dispatch_pending returns. The goal is that, in most cases, the
On Tue, Aug 19, 2003 at 10:34:22PM -0400, Pierre A. Humblet wrote:
>I got blocked from the list for the second time today,
>so I changed my address. Mail sent to the old one will
>still get to me.
What a pain. It's been a horrible day. I've been trying to do my
real job while attempting to deal
I got blocked from the list for the second time today,
so I changed my address. Mail sent to the old one will
still get to me.
At 09:16 PM 8/19/2003 -0400, Christopher Faylor wrote:
>>
>>Yep. But the 'confusion by "simultaneous" signals' was due to
>>thisproc which was set to "rc == 2"
>
>No. The
On Tue, Aug 19, 2003 at 09:32:36PM -0400, Christopher Faylor wrote:
>Although, hmm. My brain hurts. Maybe the latter behavior is more
>correct since if something is in the middle of changing the mask it will
>be guaranteed to be correct when the signal handler is finally called.
Brain still hurt
On Tue, Aug 19, 2003 at 09:23:57PM -0400, Pierre A. Humblet wrote:
>At 08:50 PM 8/19/2003 -0400, Christopher Faylor wrote:
>>On Tue, Aug 19, 2003 at 08:41:35PM -0400, Christopher Faylor wrote:
>>>However, it has been bothering me for a long time that all of this
>>>signal mask stuff is in the pinfo
At 08:50 PM 8/19/2003 -0400, Christopher Faylor wrote:
>On Tue, Aug 19, 2003 at 08:41:35PM -0400, Christopher Faylor wrote:
>>However, it has been bothering me for a long time that all of this
>>signal mask stuff is in the pinfo structure. This is a holdover from
>>early cygwin that doesn't make a
On Tue, Aug 19, 2003 at 09:06:45PM -0400, Pierre A. Humblet wrote:
>At 08:37 PM 8/19/2003 -0400, Christopher Faylor wrote:
>>On Tue, Aug 19, 2003 at 04:30:06PM -0400, Pierre A. Humblet wrote:
>>>Regarding your changes (it will take me a while to fully understand them)
>>>- What problem are you tryi
At 08:37 PM 8/19/2003 -0400, Christopher Faylor wrote:
>On Tue, Aug 19, 2003 at 04:30:06PM -0400, Pierre A. Humblet wrote:
>>Regarding your changes (it will take me a while to fully understand them)
>>- What problem are you trying to solve by having a local sigtodo?
>> Specifically now that you ha
On Tue, Aug 19, 2003 at 08:41:35PM -0400, Christopher Faylor wrote:
>However, it has been bothering me for a long time that all of this
>signal mask stuff is in the pinfo structure. This is a holdover from
>early cygwin that doesn't make any sense. So, sometime soon, I'm
>going to rip much of the
On Tue, Aug 19, 2003 at 07:31:52PM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>>
>Don't we have the same problem today?
>
>Handler is running with current mask M1, old mask M0
>New signal occurs, sigthread prepares sigsave with new mask M2, old
>mask M1
> bu
On Tue, Aug 19, 2003 at 04:30:06PM -0400, Pierre A. Humblet wrote:
>Regarding your changes (it will take me a while to fully understand them)
>- What problem are you trying to solve by having a local sigtodo?
> Specifically now that you have removed the thisproc argument in sig_handle,
> rc is no
Christopher Faylor wrote:
>
>>> >Don't we have the same problem today?
>>> >
>>> >Handler is running with current mask M1, old mask M0
>>> >New signal occurs, sigthread prepares sigsave with new mask M2, old
mask M1
>>> > but is preempted before setting sigsave.sig
>>> >Handler terminates, restores
On Tue, Aug 19, 2003 at 04:30:06PM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>
>> >Don't we have the same problem today?
>> >
>> >Handler is running with current mask M1, old mask M0
>> >New signal occurs, sigthread prepares sigsave with new mask M2, old mask M1
>> > but is preempt
Christopher Faylor wrote:
> >Don't we have the same problem today?
> >
> >Handler is running with current mask M1, old mask M0
> >New signal occurs, sigthread prepares sigsave with new mask M2, old mask M1
> > but is preempted before setting sigsave.sig
> >Handler terminates, restores M0
> >sigthr
On Tue, Aug 19, 2003 at 08:46:36AM -0400, Pierre A. Humblet wrote:
>At 12:13 AM 8/19/2003 -0400, Christopher Faylor wrote:
>>
>>I may not be able to get to your patch soon since I have actual
>>honest-to-gosh Red Hat Cygwin duties to attend to for the first time
>>in quite some time. I volunteered
At 12:13 AM 8/19/2003 -0400, Christopher Faylor wrote:
>
>I may not be able to get to your patch soon since I have actual
>honest-to-gosh Red Hat Cygwin duties to attend to for the first time
>in quite some time. I volunteered to help out on a cygwin project even
>though I've moved from the group
On Mon, Aug 18, 2003 at 10:50:10PM -0400, Pierre A. Humblet wrote:
>At 09:05 PM 8/18/2003 -0400, Christopher Faylor wrote:
>>Nevermind. It doesn't work the way I remembered. The while loop which
>>decrements sigtodo only executes once when it encounters a normal UNIX
>>signal (it probably should
On Mon, Aug 18, 2003 at 10:46:17PM -0400, Christopher Faylor wrote:
>On Mon, Aug 18, 2003 at 10:29:27PM -0400, Pierre A. Humblet wrote:
>>>However, this does demonstrate a flaw in wait_sig. It exhausts the sigtodo
>>>array based on he last received type of signal. So, if process a sends ctrl-c
>>
At 09:58 PM 8/18/2003 -0400, Christopher Faylor wrote:
>
>I only applied the reversal of the movl with the call above since I'm
>not convinced that moving the set_process_mask into interrupt_setup
>doesn't introduce a race. It seems like your code could be setting the
>signal mask in interrupt_set
At 09:05 PM 8/18/2003 -0400, Christopher Faylor wrote:
>Nevermind. It doesn't work the way I remembered. The while loop which
>decrements sigtodo only executes once when it encounters a normal UNIX
>signal (it probably should just be recoded as an if). So, this should
>be a non-issue. In fact,
On Mon, Aug 18, 2003 at 10:29:27PM -0400, Pierre A. Humblet wrote:
>>However, this does demonstrate a flaw in wait_sig. It exhausts the sigtodo
>>array based on he last received type of signal. So, if process a sends ctrl-c
>>to itself and "at the same time" process b sends ctrl-c to process a,
>
At 08:58 PM 8/18/2003 -0400, Christopher Faylor wrote:
>On Mon, Aug 18, 2003 at 08:17:36PM -0400, Pierre A. Humblet wrote:
>>5)
>>This is just an observation, about sig_handle (int sig, bool thisproc)
>>The thisproc argument is set to "rc != 2" in the sigthread. However
>>it is possible for severa
On Mon, Aug 18, 2003 at 08:17:36PM -0400, Pierre A. Humblet wrote:
>*
>2)
>movl$0,%0 # zero the signal number as a \n\
># flag to the signal handler thread\n\
On Mon, Aug 18, 2003 at 08:58:32PM -0400, Christopher Faylor wrote:
>On Mon, Aug 18, 2003 at 08:17:36PM -0400, Pierre A. Humblet wrote:
>>5)
>>This is just an observation, about sig_handle (int sig, bool thisproc)
>>The thisproc argument is set to "rc != 2" in the sigthread. However
>>it is possib
On Mon, Aug 18, 2003 at 08:17:36PM -0400, Pierre A. Humblet wrote:
>5)
>This is just an observation, about sig_handle (int sig, bool thisproc)
>The thisproc argument is set to "rc != 2" in the sigthread. However
>it is possible for several signals to occur simultaneously and a
>signal can be proce
On Mon, Aug 18, 2003 at 08:17:36PM -0400, Pierre A. Humblet wrote:
>During my work on using the multimedia timer for setitimer I noticed
>that Cygwin was not optimized to handle 1000 signals per second.
>It starts trashing under heavy load. Attached is a tune up patch.
>It also modestly improves pe
During my work on using the multimedia timer for setitimer I noticed
that Cygwin was not optimized to handle 1000 signals per second.
It starts trashing under heavy load. Attached is a tune up patch.
It also modestly improves performances at light load and fixes a
race condition.
Some explanati
49 matches
Mail list logo
