develooper Front page | perl.perl5.porters | Postings from November 2014

Re: [perl #81074] Perl reports SIGINT handler "IGNORE" not defined inmulti-threaded apps

Thread Previous
Leon Timmermans
November 30, 2014 21:13
Re: [perl #81074] Perl reports SIGINT handler "IGNORE" not defined inmulti-threaded apps
Message ID:
On Sat, Oct 4, 2014 at 10:41 AM, bulk88 via RT <>

> 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.


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About