Poll Patch
Attached is a patch for the unix/beos poll implementations using select. Basically they don't work as we'd expect them to. I found the problem during a coding session last night to get the beos MPM stopping/restarting. The problem is that when we create and setup the pollset we add the fd's to the fd_set and then pass the fd_set into select, where it gets altered, and hence looses some of the information. Imagine the following fd_set has fd 0 and fd 1 select waits for data on fd 0 and fd 1 select finds data on fd 1 fd_set now has fd 1 select waits for data on fd 1 ! :( Not good. This basically means that the select based impl. doesn't have the same behaviour as the poll one and that's something we need to fix. The patch basically adds a second set of fd_set's to the pollset and when you add/remove fd's from the pollset, you affect the new fd_sets. Just before we actually go into select, we copy the new fd_set's into the fd_set we pass to select, and store the results as before. I've tested it on BeOS and if no-one objects I'll commit on Thursday afternoon (GMT). This will impose a bit of a performance penalty, and there may be a better solution, but this works and is simple enough that it illustrates the problem nicely. david poll_patch.dat Description: Binary data
Re: disk i/o problems
Ben Collins-Sussman <[EMAIL PROTECTED]> writes: > Hi all -- I'm getting some weird disk slowdowns on FreeBSD 4.2. Did you by chance look at an strace/truss of your APR app on Linux and FreeBSD to see what APR is doing on your file? Are you using buffered APR file support? > I think we need to investigate APR and see where the "portability" has > gone astray... what system interfaces changed in FreeBSD 4.2 that so > dislike APR's file routines? Anyone have ideas? There really isn't much code to look at for file I/O. But first I think you might want to look at a syscall trace and see if we're doing the right thing. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: libtool in apr/shmem/unix/mm
[EMAIL PROTECTED] wrote:
>
> MM is a strange beast, because it is an import of an external project. My
> own opinion is that we should completely remove MM, because it is more
> than APR needs, and it doesn't really work the way I want it to. However,
> because I don't have time to replace it, we should make it fit cleanly
> into APR.
>
> I would like to see MM's configure script use APR's version of libtool, et
> al.
For this, the patch looks easy - Find it enclosed -
The additional thing is to remove the following file from cvs:
config.guess
config.sub
ltconfig
ltmain.sh
About removing files from CVS I think these 2 files should be removed from APR:
build/config.guess
build/config.sub
They are from libtool and are regenerated by buildconf.
>
> Just my 0.02.
>
> Ryan
>
> On Wed, 21 Mar 2001, jean-frederic clere wrote:
>
> > Hi,
> >
> > I have detected that the libtool files are in the cvs of
> > apr/shmem/unix/mm...
> > config.guess, config.sub, libtool ...
> > That an old version of libtool (1.3.4).
> >
> > I think that apr/shmem/unix/mm should work like the rest of apr: buildconf
> > should create the needed tools.
> >
> > Cheers
> >
> > Jean-frederic
> >
> >
>
> ___
> Ryan Bloom [EMAIL PROTECTED]
> 406 29th St.
> San Francisco, CA 94131
> ---Index: shmem/unix/mm/aclocal.m4
===
RCS file: /home/cvs/apache/apr/shmem/unix/mm/aclocal.m4,v
retrieving revision 1.9
diff -u -r1.9 aclocal.m4
--- shmem/unix/mm/aclocal.m42000/12/31 12:26:41 1.9
+++ shmem/unix/mm/aclocal.m42001/03/21 14:50:55
@@ -57,8 +57,8 @@
test ".$ac_cv_prog_gcc"= .yes && libtool_flags="$libtool_flags --with-gcc"
test ".$ac_cv_prog_gnu_ld" = .yes && libtool_flags="$libtool_flags
--with-gnu-ld"
CC="$CC" CFLAGS="$CFLAGS" CPPFLAGS="$CPPFLAGS" LD="$LD" \
-${CONFIG_SHELL-/bin/sh} ltconfig --no-reexec \
-$libtool_flags --no-verify ltmain.sh $PLATFORM ||\
+${CONFIG_SHELL-/bin/sh} $ac_aux_dir/ltconfig --no-reexec \
+$libtool_flags --no-verify $ac_aux_dir/ltmain.sh $PLATFORM ||\
AC_MSG_ERROR([libtool configuration failed])
LIBTOOL="\$(TOP)/libtool"
AC_SUBST(LIBTOOL)
APR_FLAG_FUNCS ?
Would it make sense to migrate over to APR_FLAG_FUNCS? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "Hell is hot, that's never been disputed by anybody."
Re: libtool in apr/shmem/unix/mm
MM is a strange beast, because it is an import of an external project. My own opinion is that we should completely remove MM, because it is more than APR needs, and it doesn't really work the way I want it to. However, because I don't have time to replace it, we should make it fit cleanly into APR. I would like to see MM's configure script use APR's version of libtool, et al. Just my 0.02. Ryan On Wed, 21 Mar 2001, jean-frederic clere wrote: > Hi, > > I have detected that the libtool files are in the cvs of apr/shmem/unix/mm... > config.guess, config.sub, libtool ... > That an old version of libtool (1.3.4). > > I think that apr/shmem/unix/mm should work like the rest of apr: buildconf > should create the needed tools. > > Cheers > > Jean-frederic > > ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
libtool in apr/shmem/unix/mm
Hi, I have detected that the libtool files are in the cvs of apr/shmem/unix/mm... config.guess, config.sub, libtool ... That an old version of libtool (1.3.4). I think that apr/shmem/unix/mm should work like the rest of apr: buildconf should create the needed tools. Cheers Jean-frederic
