httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: pid or proc
Date Thu, 18 May 2000 11:38:08 GMT

>    long ap_pid_long(ap_proc_t *pid);
> which just seemed to go one pid further than was worth piddling over.
> Of course, I'd prefer that it just return pid_t, but that would require
> adding another formatting variable to snprintf in order to avoid that
> other warning on Solaris (which, after all, doesn't have int pids).

This has already been implemented.  Try looking at the
ap_get_os_proc() call in apr_portable.h

> But that got me thinking... why the heck do we have this other ap_proc_t
> type anyway when the only useful thing we do with it is store a pid?
> Onward to the code in apr/threadproc, which unfortunately lacks any
> overview comments that would explain why this thing might be useful,

The comments were there at one point, and for the most part, the overview
comments and why this thing is useful are all in the API docs, which have
been moved to apr_threadproc.h

Now, as far as the only useful thing being to store a pid.  This is just
plain wrong.  Yes, on Unix the only useful thing is to store a pid,
because the programmer can handle the rest themselves.  On other
platforms, like say... Windows, where the programmer can't do anything
between the fork and exec, there is a lot of useful stuff that can be
stored in an ap_proc_t.  The goal of APR is NOT to make every platform
look like Unix, because you can't do that, I tried for the first
month.  The goal of APR is to make all platforms look alike, and to have
the resemble POSIX where _possible_.  When it comes to processes, that's
just not possible.

To see what other useful stuff can be in the ap_proc_t variables, take a
look at the pipes that are associated with a proc_attr, which is in turn
associated with the proc.  Or, how about the directory to switch to after

> it would seem that ap_proc_t is being used for process-local storage,
> or at least that's my best guess.  At least in some places it is.
> There are also some places there where pid is defined as an int
> and proc just doesn't even enter the picture.

Those are bugs.

> So, I am stumped.  To fill out the documentation, I have a few Qs:
>   1) define ap_proc_t as an abstract data type:
>      -- what is its purpose;
>      -- what does it contain, and why;

See above, and the code, and the docs which have been placed in

>      -- what is the expected lifetime of an instance (i.e., is there
>         some expectations regarding its creation/destruction that I
>         need to know before I go fiddling with it) especially in
>         regard to its pool;

A process lives as long as it's pool.  When the pool's cleanups are
called, the process should be killed.  This may not currently be
happening, I have forgotten.

>      -- how is it likely to differ across platforms.

In all sorts of ways, but the biggest differences are implementation
details.  On Unix the ap_proc_t's have a pid, on BeOS, it is called a pid,
but it is really a thread_id, On Windows the ap_proc_t has a
PROCESS_INFORMATION pointer, which I assume has a pid internally.

This BTW, is why we are using incomplete types.  It is a whole lot easier
to just tell people they can't have access to a certain type then to try
to figure out how that type maps to each platform's individual types.

>   2) pid_t is the only reasonable way to identify a process, even on
>      platforms that have no pid_t, so the user is going to need access
>      to this component regardless of how ap_proc_t is implemented.
>      What is the right way to grant that access?

Please tell MS and BeOS that they are idiots then, because they seem to
disagree with you.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message