apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [PATCH] Re: cvs commit: apr/threadproc/unix proc.c
Date Tue, 16 Oct 2001 05:43:35 GMT
On Monday 15 October 2001 10:38 am, Jeff Trawick wrote:

I seriously doubt that we want to extend the apr_proc_t type anymore.  Having
this type be complete has caused Windows to have to jump through hoops to
keep track of processes correctly, and adding more to it is a mistake IMO.

Also, I would completely ignore stopped processes, because I have a feeling
that they aren't portable at all.  Finally, I would do this with just another argument
to apr_proc_wait_*.  All we need is a simple enum that tells us how the process
died, either normally or because of a signal.

I would also get rid of the native exit code.  In general, APR doesn't expose
information like this to the user.  There are two locations that is not true, error
codes, and processes.  Error codes are done this way, because we have
created macros to compare the codes.  Processes are a mistake, and they
really should have remained incomplete types.

Opening up a third location where we expose the native result to the uesr is
just making programs less portable.  From everything that I have read in this
thread, we are looking for two pieces of information.

	1)	Did the process die normally
	2)	What was the exit code or signal

Adding another int * to the argument list allows us to return both pieces
of information cleanly and easily.


> This patch implements (for Unix, at least) what I mentioned in a
> previous post, namely, to make available all information about a
> terminated child but to classify it so that a portable app doesn't
> have to play games with WIFEXITED() et al.
> As I mentioned before, I don't know if we're doing the right thing on
> Unix w.r.t. capturing information about processes which are stopped.

Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message