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

Re: The future of POSIX in core

Thread Previous | Thread Next
From:
Leon Timmermans
Date:
September 2, 2011 13:40
Subject:
Re: The future of POSIX in core
Message ID:
CAHhgV8gyfte6WU2GJRCMu=iyc=c1SJ=nnoG2SwKaM9qv_zvx4w@mail.gmail.com
On Fri, Sep 2, 2011 at 5:05 PM, Nicholas Clark <nick@ccl4.org> wrote:
> What does this gain? I don't think that it simplifies anything.
>
> POSIX::SigAction would always be loaded by POSIX::SigRT (because the
> latter uses the former) and POSIX::SigRT would always be loaded by POSIX
> (because %POSIX::SIGRT is implemented by the methods in POSIX::SigRT)
>
> It would increase the number calls to stat() and open() to load POSIX,
> without (I think) reducing in any way the compile time or runtime resources
> needed.

It does matter in the sense that currenly «use POSIX::SigAction;»
doesn't work. Nor does something like «use parent 'POSIX::SigSet';».

In a related note, can anyone explain me what %POSIX::SIGRT is needed
for? %SIG seems to handle real time signals just fine. Why does it use
*unsafe* signals? Does my second question answer my first? Why it has
this strange signal naming convention that differs from what the core
($Config{sig_name}) uses? Why is this convention not documented? Why
it doesn't have tests? Has anyone ever used it for anything?

Leon

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About