Re: [boost] [GSoC] Some Ideas about the Boost.Process

Subject: Re: [boost] [GSoC] Some Ideas about the Boost.Process
From: Bruno Santos (bsantos_at_[hidden])
Date: 2010-03-25 21:22:01

Qui, 2010-03-25 Ã s 18:16 -0300, Felipe Tanus escreveu:
> Boris, Thanks for your answer
> 
> On Thu, Mar 25, 2010 at 5:51 PM, Boris Schaeling <boris_at_[hidden]> wrote:
> > As far as I am concerned Boost.Process shouldn't be required to support
> > signals. First there are already so many other things to do.
> 
> True.
> 
> > Second it's
> > true that Windows doesn't support signals at all (apart from those two you
> > mentioned and I think SIGFPE). You are then in POSIX land anyway?
> 
> Windows support signals. I got this from signal.h (from a windows system):
> 
> [quote]
> #define SIGINT        2       /* interrupt */
> #define SIGILL       4       /* illegal instruction - invalid function image */
> #define SIGFPE        8       /* floating point exception */
> #define SIGSEGV       11      /* segment violation */
> #define SIGTERM       15      /* Software termination signal from kill */
> #define SIGBREAK      21      /* Ctrl-Break sequence */
> #define SIGABRT       22      /* abnormal termination triggered by
> [/quote]
> 

Don't get yourself fooled by that, that is just the C library. When you
setup a handler for the SIGBREAK a background thread is created which
waits for Control-C notifications (see the win32 console API) and then
runs the handler.

To make this clear, the win32 subsystem does not support signals!
By the way, the POSIX subsystem uses an undocumented NT mechanism (a
debug port) to properly implement signals.

>
> More info in MSDN[1]
> 
> > Thus I wouldn't care about signals for now.
> 
> I got your point. There is more work to do instead keep adding
> unfinished features to the lib. In my proposal, I'll not include this,
> but I would like to program this someday.
> 
> 
> [1] http://msdn.microsoft.com/en-us/library/xdkz3x12%28VS.71%29.aspx
> 
>