Front page | perl.perl5.porters |
Postings from November 2014
Re: [perl #81074] Perl reports SIGINT handler "IGNORE" not defined inmulti-threaded apps
Thread Previous
From:
Leon Timmermans
Date:
November 30, 2014 21:13
Subject:
Re: [perl #81074] Perl reports SIGINT handler "IGNORE" not defined inmulti-threaded apps
Message ID:
CAHhgV8hjYmp-Ze_=REBngcnbuCqsQHmdu_VbrEvT=UT9=NQJzA@mail.gmail.com
On Sat, Oct 4, 2014 at 10:41 AM, bulk88 via RT <perlbug-followup@perl.org>
wrote:
> If you grep / and /win32 for "curinterp" you will see that is already done
> in win32.c . I am not saying it is right or wrong. On win32 Perl there is a
> race condition that nobody ever solved regarding the Ctrl-C signal on
> Win32. Win32 API will always call the Ctrl-C function from a fresh thread.
> If perl is at 100% cpu in runloop without being stuck in kernel mode, and
> Ctrl-C is pressed, there is a race between my_exit() and the code executing
> in runloop. Usually the OP * is freed while the PP func is running and
> somehow usually a NULL is returned and the runloop quickly exits if the
> sign handler thread doesn't reach C lib exit() first. Maybe this code is
> needed for Win32 too.
>
I'm not aware of a pthread_kill equivalent on Windows, nor do I really know
how signal delivery in multi-threaded windows programs works.
> > Also, it should be noted that your additions feature is enabled on
> > USE_ITHREADS, even though your solution is multiplicity based and the
> > problem is also a multiplicity issue. Then again, the solution I
> suggested
> > for your race condition is assuming ithreads. I'm not sure how to deal
> with
> > that, possibly by not caring.
>
> I agree. AFAIK MULTIPLICITY is dead but the token remains for backcompat
> since 5.005 threads are gone. PERL_IMPLICIT_CONTEXT is what you probably
> want. PERL_IMPLICIT_CONTEXT *without* USE_ITHREADS means you want multiple
> perl threads/interps in 1 process for embedding reasons, but you do not
> want the ithreads module. So what happens if the signal is delivered to a
> 3rd party GUI or IO OS thread while the OS thread with Perl is blocked?
>
If you define one of MULTIPLICITY and PERL_IMPLICIT_CONTEXT the other will
automatically be defined, though AFAIK we did support MULTIPLICITY without
PERL_IMPLICIT_CONTEXT as some point. Using MULTIPLICITY without using
ithreads is still supported, though I'm not aware of anyone using that (I
have some ideas here).
> -----------------------------------------
> @@ -1573,9 +1599,17 @@ Perl_magic_setsig(pTHX_ SV *sv, MAGIC *mg)
> PL_psig_ptr[i] = NULL;
> }
> }
> +#ifdef USE_ITHREADS
> + if (!PL_sighand_set) {
> + Newxz(PL_sighand_set, SIG_SIZE, int);
> + }
> -----------------------------------------
>
> Can PL_sighand_set be an inline array in interp struct? Im not sure of
> details since this is unix, but I'm afraid this array will wind up always
> getting allocated in every run of the interp, and therefore malloc overhead
> for something that will be unconditionally allocated if an interp struct
> was allocated. Also if the malloc design stays. Dont let Newxz use
> PL_sighand_set, instead let it use a C auto void pointer, then assign the C
> auto to PL_sighand_set, that way the sig handler func wont see half zero-ed
> data where PL_sighand_set was set, but memset hasnt been called yet, or
> memset is half way done zeroing the block. I didn't trace exactly how the
> Newxz macros work but assume Newxz can cause half zeroed data.
>
AFAICT it will be alloced when a %SIG entry is set, which isn't
unconditional. It may sill be worth inlining into the interp struct though.
Leon
Thread Previous