develooper Front page | perl.perl5.porters | Postings from May 2004

RE: Embedding Perl in a C++ program changes Ctrl+C handler

Thread Previous | Thread Next
From:
Mikko Noromaa
Date:
May 21, 2004 06:02
Subject:
RE: Embedding Perl in a C++ program changes Ctrl+C handler
Message ID:
20040521130144.3301.1@llama.elixent.com
Hi,

Thank you for your reply!

> My understanding is that multiple SetConsoleCtrlHandler's can 
> be active. Latest one defined gets called 1st.

Yes and no:
Yes, Win32 allows multiple SetConsoleCtrlHandler's.
No, Perl doesn't.

In perl-5.8.4\win32\win32.c, function win32_ctrlhandler() returns always
TRUE. This means that no other handlers set by SetConsoleCtrlHandler get
called. This way Perl is monopolizing a system resource that might be needed
by other parts of my program.

> Perl registers a handler so that $SIG{INT} can be used to 
> allow perl-level graceful termination.

If Perl is embedded, I don't see any reason for Perl to do this. It is the
embedding program's responsibility to handle graceful termination.

> Embeddding perl is always something we come to AFTER we 
> have perl itself working.

OK, I understand that. My suggestion is to remove ALL code paths that lead
to exit() when running Perl in an embedding scenario. A better place for
global clean-up is in the DllMain() function on DLL_PROCESS_DETACH. On the
other hand, it might be too late to do certain kinds of uninitialization
here. The best (and only!) way then is to have all the uninitialization done
in a function called by the embedding program (like perl_destruct and
perl_free).

> I/(we-on-perl5-porters) are weak on Win32 good practice.
> It calls exit() if you haven't given it a handler to 
> so something more specific.

I think my program is a good example of why exit() is bad. My program is a
service that runs several threads all doing different things. One of the
threads is running Perl scripts. In no case do I want this one thread to
terminate my whole application! The single thread, maybe, but even so I'd
appreciate it if I could count on functions like perl_run() and
perl_call_XX() to always return.

I don't think this has anything to do with Win32. I think the same problem
could easily appear in a similar scenario on Unix!

> The easiest thing to do is probably use perl's handler to do 
> your cleanup - (i.e. have your C++ code define an XSUB and set
> $SIG{INT} to that.

Thanks for the tip, but unfortunately it did't work. I tried the following:

$SIG{'INT'} = 'IGNORE';

This makes Perl, and my program, ignore the whole signal. This is because
the console handler of Perl returns always TRUE (see above).

> I don't see why defining your handler after perl's is a "last resort".

Because that would require a change in the whole structure of my program. My
program is using Perl as an add-on that is used only in certain special
circumstances. Also, I don't really need Ctrl+C handling for anything else
than debugging because my program normally runs as a service.

In addition, I don't really know when Perl sets its control handler. Is it
in perl_alloc, perl_construct, perl_parse, perl_run(), or perhaps all of
these? Worse yet, is it during running a script (e.g. $SIG{INT}='DEFAULT')?
Even if I checked this from the Perl sources, I couldn't be sure if newer
Perl versions change it.

--

Mikko Noromaa (mikkon@nm-sol.com) - tel. +358 40 7348034
Noromaa Solutions - see http://www.nm-sol.com/
 

> -----Original Message-----
> From: Nick Ing-Simmons [mailto:nick@ing-simmons.net] 
> Sent: Tuesday, May 18, 2004 11:55 AM
> To: mikkon@nm-sol.com
> Cc: perl-win32-porters@listserv.ActiveState.com
> Subject: Re: Embedding Perl in a C++ program changes Ctrl+C handler
> 
> 
> Mikko Noromaa <mikkon@nm-sol.com> writes:
> >Hi,
> >
> >I am creating a Win32 application that is capable of running 
> Perl scripts. I
> >have created a separate thread that is the only part of my 
> application that
> >uses the Perl interpreter. In that thread, I use perl_alloc(),
> >perl_construct(), perl_parse() and perl_run() to run Perl scripts.
> >
> >This all works fine except for one annoying small detail: 
> when I press
> >Ctrl+C in my application, I get the following message and my 
> whole program
> >terminates:
> >
> >Terminating on signal SIGINT(2)
> >
> >I have registered a Ctrl+C handler in my application with 
> the Win32 function
> >SetConsoleCtrlHandler(). I use this handler to close my application
> >gracefully. Perl apparently sets its own Ctrl+C handler, 
> which overrides my
> >handler because my Perl thread is initialized later.
> 
> My understanding is that multiple SetConsoleCtrlHandler's can 
> be active. Latest one defined gets called 1st.
> 
> Perl registers a handler so that $SIG{INT} can be used to 
> allow perl-level graceful termination.
> 
> >
> >First: I think this is a bug in the Perl libraries. When 
> embedding Perl, it
> >should not modify process-level behaviours like the Ctrl+C handler.
> 
> Possibly. Embeddding perl is always something we come to AFTER we 
> have perl itself working.
> 
> >Especially it is a very bad practise to call ExitProcess() 
> from a Ctrl+C
> >handler that belongs to a DLL!
> 
> I/(we-on-perl5-porters) are weak on Win32 good practice.
> It calls exit() if you haven't given it a handler to 
> so something more specific.
> 
> >
> >Second: What is the recommended way of working around this 
> problem? Can I
> >somehow disable Perl's Ctrl+C handler? Of course, I could do my own
> >SetConsoleCtrlHandler() call every time after Perl 
> initializations, but I
> >don't like this. I'd like to leave this as the last-resort option.
> 
> The easiest thing to do is probably use perl's handler to do 
> your cleanup - (i.e. have your C++ code define an XSUB and set
> $SIG{INT} to that.
> 
> I don't see why defining your handler after perl's is a "last resort".
> 
> >
> >I am using ActiveState Perl v5.8.3 build 809, and the 
> Perl58.dll that came
> >with this package.
> >
> >--
> >
> >Mikko Noromaa (mikkon@nm-sol.com) - tel. +358 40 7348034
> >Noromaa Solutions - see http://www.nm-sol.com/
> >
> >
> >
> >_______________________________________________
> >Perl-Win32-Porters mailing list
> >Perl-Win32-Porters@listserv.ActiveState.com
> >To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
> 
> 
> 


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