develooper Front page | perl.perl5.porters | Postings from September 2011

Re: The future of POSIX in core

Thread Previous | Thread Next
Leon Timmermans
September 2, 2011 15:25
Re: The future of POSIX in core
Message ID:
On Fri, Sep 2, 2011 at 10:58 PM, Nicholas Clark <> wrote:
> Possibly Jarkko. It came from him in commit 3609ea0df8ff1318. There's not
> much more detail in his e-mail:
> There is also this comment in the documentation:
>  but the right POSIX moves (see below) are made with
>  the POSIX::SigSet and POSIX::sigaction instead of accessing the %SIG.

I had already checked the commit and the comment, it was fairly unhelpful sadly.

>> *unsafe* signals? Does my second question answer my first? Why it has
> I'll guess that it's only really useful if one uses the SA_SIGINFO flag
> to get the extra info, and that (currently) only works with unsafe signals.

That was my best guess too, but it still doesn't make sense.
SA_SIGINFO is just as useful with ordinary signals, and unsafe signals
are just as dangerous.

>> this strange signal naming convention that differs from what the core
>> ($Config{sig_name}) uses? Why is this convention not documented? Why
> I don't see any POSIX RT signals in the list of signal names in
> on FreeBSD or OS X.

What about `kill -l`?

> I see some names on a Linux system, but they don't
> correspond to this comment in
>   # Allow (SIGRT)?MIN( + n)?, a common idiom when doing these things in C.

It's not that problematic that real time signals don't have
standardized names, but it is annoying.

>> it doesn't have tests? Has anyone ever used it for anything?
> As to the rest, I don't know. "Jarkko", or "ask Jarkko" are my best guess
> answers.

Yeah, I guess I'll have to do that.


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