httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject pid or proc
Date Thu, 18 May 2000 05:34:57 GMT
I started to fix a bug in mpmt_pthread.c where a pid variable is being
printed as an int even though it is actually a pointer to a proc which
points to an incomplete struct type that contains a pid.  Unfortunately,
the easy fix wouldn't work because you can't just dereference an
incomplete type to get the pid from the proc.  Bummer.  Then I noticed
that there are several cases where a pid variable is used and defined as
an int, even though it should always be defined as a pid_t.  Well, that
sucks.  So I continued on to see if I should change the pid type of the
first pid to be complete so that I can access it directly, or define an
access function like

   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).

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,
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.

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;
     -- 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;
     -- how is it likely to differ across platforms.

  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?


View raw message