public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Houder <houder@xs4all.nl>
To: cygwin@cygwin.com
Subject: Re: REVISITED: Signal delivered while blocked
Date: Sun, 20 Aug 2017 13:20:00 -0000	[thread overview]
Message-ID: <eec2ed14107eea3a5a71e344b8e8e9dc@smtp-cloud7.xs4all.net> (raw)
In-Reply-To: <20170818162040.GC6314@calimero.vinschen.de>

On Fri, 18 Aug 2017 18:20:40, Corinna Vinschen wrote:
> On Aug 16 23:22, Houder wrote:
[snip]

> > The alternative testcase in fact consists of 2 testcases (2 files):
> >
> >  1. sigprocmask-exclusion4.c
> >  2. sigprocmask-exclusion5.c

> Thanks for the testcases.  This is still a pretty tricky problem and a

Providing a proper testcase was my sole purpose (intention?). That is,
to help you (i.e. to prevent you from waisting your precious time).

Though Noah believes that my modification of his testcase is uncalled
for.

Consequently, it is up your discretion :-)

> few hours of debugging haven't shown anything conclusive.  The signal
> code was my former co-maintainer's domain, so I'm not as fluent in
> debugging it.

Got it, "Advantage Christopher Faylor, disadvantage Corinna Vinschen"!

Perhaps Christopher would be willing to lend you a hand here ... for old
times' sake ... or as an once-only challenge (to proof to himself, he can
still do it :-))

> ATM it looks like a race inside of the Cygwin DLL to me.  The checks if
> a signal should be handled and the *creation* of the call to the signal
> handler (but *not* the actual call to the signal handler) may occur
> before the signal is blocked, while the call then occurs after the
> blocking.

My impression as well (however, in my case it was based on the results of
the testcases).

.. uhm, in "U/Linux land" the delivery of a signal is "immediate", once
the process returns to the kernel ... (i.e. the stack of the process is
adjusted with a call to the signal handler before it will continue).

.. signal handler A is not allowed to continue (and block signal B) if
the kernel has decided that signal handler B should run.

That is, it is what I remember from old times ...

> Anyway, I'm not sure I have enough time to fully immerse into that
> problem any time soon.  I'd be not too unhappy if somebody would try to
> debug this in the Cygwin DLL, too...

I hear you. However I am not capable to help you here ... Perhaps somebody
else can ... a much younger person than I am.

Regards,

Henri

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  reply	other threads:[~2017-08-20 13:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16 21:22 Houder
2017-08-18 16:20 ` Corinna Vinschen
2017-08-20 13:20   ` Houder [this message]
2017-08-20 12:59 ` Houder
2017-08-20 15:44 ` Kaz Kylheku

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eec2ed14107eea3a5a71e344b8e8e9dc@smtp-cloud7.xs4all.net \
    --to=houder@xs4all.nl \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).