httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] Compiler warning + 64-bit AIX cleanup in dexter mpm
Date Thu, 22 Jun 2000 00:50:04 GMT

> > Couldn't this entire patch be avoided by just defining ap_os_sock_t to be
> > a long on 64-bit AIX?  
> 
> not sure...  even if so, I'd hate to use more storage and more
> instructions everywhere just to avoid an idiosyncrasy in struct
> pollfd... 
> 
> >                              Or, are you saying that file descriptors have
> > different sizes in difference cases on 64-bit AIX.  
> 
> File descriptors are always int in AIX as far as we could tell.  The
> fd field in struct pollfd is larger than int because it needs to be
> able to hold things that are larger than file descriptors.

If file descriptors are always int's, then we can't just re-define
ap_os_sock_t.  Oh well, that was worth a shot.

> > Having looked at the AIX API, it looks like they are overloading the poll
> > API to allow the first argument to be a pointer to either a pollfd, a
> > pollmsg, or a pollist.  Ugggh.
> 
> We looked at the fd field in struct fd in sys/poll.h to understand why
> it was not int and the comment said something like "file descriptor or
> file offset".  I see that they didn't mention this little detail in
> the manual I just found on-line.  Maybe the change is with 4.3.3...

Unfortunately, in doing this, they are also going against the Single Unix
Specification.  I really hate the fact that they are doing this.

> > I have one suggestion that I would also like to try to remove this
> > problem.  I would be interested in seeing if we have the same problem if
> > we use select instead of poll.  
> 
> We wouldn't have the problem with select().

Why not just have dexter use select instead of poll then?  I realize this
will actually require a larger re-write, but it will make all of the code
make sense.  I can just see somebody coming along in a year and trying to
make the code easier to read/understand and undoing this change.  This
means that we need to document the reasons behind this everyplace we run
into this problem.

> >                                   If not, we can make dexter use ap_poll
> > instead of poll, and then make APR decide to use select on 64-bit
> > AIX.  
> 
> 1) ap_poll() is slower than poll() and dexter doesn't need the
>    portability that ap_poll() gives it

When was this proven?  Does it really matter that the parent process runs
a tiny bit slower when it is polling on sockets?

Since when was it decided dexter doesn't need to be portable?  Currently,
dexter uses pthreads, I didn't realize that was never going to
change.  Does this mean that any platform that doesn't provide poll can't
use dexter?  I dislike this answer personally.  The mpmt_pthread MPM is
using ap_poll for this feature.  Why does it need to be more portable than
dexter?

>    I'd rather have the several extra lines of code in dexter than the
>    extra pathlength requierd for ap_poll().  The few extra lines of
>    code are unfortunate, of course, but at least they are much easier
>    to verify than the code required to convert to ap_poll().

The code to convert to ap_poll has already been written.  Look at
mpmt_pthread.  In fact, that code should be common.  In fact, if you look
at mpmt_pthread and dexter, I have a feeling that most of the code could
and should be common.  I dislike this answer personally.

> > get the feeling that this problem is going to bite us over and over again
> > if we use the proposed patch.
> 
> I think there are only two callers of the poll() system call in in all
> of Unix-land: ap_poll() and dexter.  More could be added, of course,
> but that seems unlikely with ap_poll().

I am still having trouble with the argument that this one shouldn't be
converted to use ap_poll.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message