Re: [boost] Proposal: Library to manage processes

From: Mark Deric (laguna_at_[hidden])
Date: 2005-02-21 00:44:32

On Sun, 20 Feb 2005 16:17:22 -0700
"Jeff Garland" <jeff_at_[hidden]> wrote:

> On Sun, 20 Feb 2005 12:03:46 -0700, Jeff Garland wrote
> 
> > Before you embark on the project you should be aware of some of the
> > other libraries in the eco-system:
...
> > Also, ACE has tools for doing this, although the interface is quite
> > complex and doesn't integrate with I/O streams.

Until I found boost about 4 years ago, ACE was my favorite place to
learn about pragmatic, esoteric C++ thinking.  So, concur on finding out
"what's out there".  BTW, was just looking at William Kempf's work
w/ReadWrite locks; and who should show up prominently in the references:
Doug Schmidt!  Also, the suggestion to put together the lib doc in
advance of the work makes total sense ... begin at the end.  This is a
valuable, non-trivial undertaking.  I'm inclined to figure out how
Boost/DocBook works so I can help.  Somebody call me out on that!

If we're going to manage processes; we ought to advantage ourselves by
knowing whether the process is foreign (as in Julio's VC example) or one
that is in our framework.  One might say that this is mixing metaphors,
managing processes vs being a process, but the ACE idea relates them. 
This is appropriate in lots of multi-daemon systems.  So, to say that
"it's quite complex and doesn't integrate with I/O streams" may be
throwing the baby out with the bath water. (Though it is complex and...,
and not nearly as tight as boost.)  Otherwise, this is a cross platform
packaging job on the

pid_t fork_and_exec_piped(char **argv, int *infd, int *outfd, int
*errfd)

C function that we all have written.

While this may be compelling in the context of Jonathan Turkanis
"system_filter; system_source; system_sink" notion (and I don't write
that off); the "process control" picture is bigger.  There's the SIGCHLD
handler issue (see Jeff Garland's archive reference).  And the Runnable
base class; which mates threads and processes in their derivations (and
is more highly evolved than the Java counterpart).

Consider "being a process".

To get away from "C" main as fast as possible:

class PTest : public app_base //derived from runnable

int main(int argc, char **argv)
{
    return main_delegate<App>(argc, argv);
}

app_base offers

register_sighandler(SIGINT, &exit_requested, &sig_handler<App>)

and set ability for private members

std::istream& appin
std::ostream& appout
std::ostream& apperr

I would have written boost::stdin, but I'm a slow dinosaur, and can't
write it until I read it.

Regards,
Mark