public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* converting signals to C++ exceptions
@ 2002-07-22 14:03 Alexy Khrabrov
  2002-07-22 15:36 ` Gokhan Kisacikoglu
  0 siblings, 1 reply; 3+ messages in thread
From: Alexy Khrabrov @ 2002-07-22 14:03 UTC (permalink / raw)
  To: gcc-help


Is there a reasonable way to convert Unix signals
to C++ exceptions on Linux with g++?

Cheers,
Alexy

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: converting signals to C++ exceptions
  2002-07-22 14:03 converting signals to C++ exceptions Alexy Khrabrov
@ 2002-07-22 15:36 ` Gokhan Kisacikoglu
  2002-07-22 23:33   ` Todd Kokoszka
  0 siblings, 1 reply; 3+ messages in thread
From: Gokhan Kisacikoglu @ 2002-07-22 15:36 UTC (permalink / raw)
  To: Alexy Khrabrov; +Cc: gcc-help

I am not sure this can be done. Unix signals are handled by service
functions that you install prior, they are invoked regardless the state
of your program (even though it is more than likely that your program is
causing the signal other than few system resource problems). So, once
the signal is handled by your handler function, it will not return where
your program was left off, the handler function decides on what to do
next -most of the time your program is expected to exit anyway. Hence,
it is probably not possible to apply a catch method, because the unix OS
would not know which catch to call when your handler function returns
-there can be several instances in the memory that could handle-, but
you can call the same clean up functions that you would call at the
catch construct from the handler function -basically, you just need to
keep few globals around to find out the leaking data or the data to be
recovered...

HTH,
Gokhan

Alexy Khrabrov wrote:
> 
> Is there a reasonable way to convert Unix signals
> to C++ exceptions on Linux with g++?
> 
> Cheers,
> Alexy

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: converting signals to C++ exceptions
  2002-07-22 15:36 ` Gokhan Kisacikoglu
@ 2002-07-22 23:33   ` Todd Kokoszka
  0 siblings, 0 replies; 3+ messages in thread
From: Todd Kokoszka @ 2002-07-22 23:33 UTC (permalink / raw)
  To: Gokhan Kisacikoglu; +Cc: Alexy Khrabrov, gcc-help

This is a C++ installation of standard system libraries. I haven't used it
though.

http://www.cs.wustl.edu/~schmidt/ACE-overview.html


On Mon 22 Jul 2002 at 15:38:58 -0700, Gokhan Kisacikoglu wrote:
> 
> I am not sure this can be done. Unix signals are handled by service
> functions that you install prior, they are invoked regardless the state
> of your program (even though it is more than likely that your program is
> causing the signal other than few system resource problems). So, once
> the signal is handled by your handler function, it will not return where
> your program was left off, the handler function decides on what to do
> next -most of the time your program is expected to exit anyway. Hence,
> it is probably not possible to apply a catch method, because the unix OS
> would not know which catch to call when your handler function returns
> -there can be several instances in the memory that could handle-, but
> you can call the same clean up functions that you would call at the
> catch construct from the handler function -basically, you just need to
> keep few globals around to find out the leaking data or the data to be
> recovered...
> 
> HTH,
> Gokhan
> 
> Alexy Khrabrov wrote:
> > 
> > Is there a reasonable way to convert Unix signals
> > to C++ exceptions on Linux with g++?
> > 
> > Cheers,
> > Alexy
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-07-23  6:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-22 14:03 converting signals to C++ exceptions Alexy Khrabrov
2002-07-22 15:36 ` Gokhan Kisacikoglu
2002-07-22 23:33   ` Todd Kokoszka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).