cvs commit: src/lib/libpthread Makefilesrc/lib/libpthread/thread thr_acl_aclcheck_fd.c thr_aio_suspend.c thr_attr_get_np.c thr_attr_init.c thr_attr_setcreatesuspend_np.c thr_attr_setguardsize.c thr_attr_setschedparam.c thr_attr_setscope.c ...

Daniel Eischen eischen at
Fri Apr 18 10:49:19 PDT 2003

On Fri, 18 Apr 2003, Robert Watson wrote:
> On Thu, 17 Apr 2003, Daniel Eischen wrote:
> >   This library now passes all of the ACE tests that libc_r passes
> >   with the exception of one.  It also seems to work OK with KDE
> >   including konqueror, kwrite, etc.  I haven't been able to get
> >   mozilla to run due to lack of java plugin, so I'd be interested
> >   to see how it works with that.
> Great news!  Since things are now beginning to get to the usefully
> runnable stage, could you (without investing too much time) answer two
> questions:
> (1) Do we have any experience getting KSE up and running on SMP hosts?

I don't have an SMP box, but David Xu is working on it.  There
is currently a problem getting one of his tests to work with
an SMP kernel whereas it works with a UP kernel.  This is
with only one KSE.

There are few things that we are working on:

   o Cleanup existing code looking for locking problems and
     bugs in general.

   o Fixing signal handling; the libthr signal changes broke
     this for us, and the current code has some hacks to try
     and work around it.  It's not perfect, so don't expect
     signals to work fully yet.

   o Getting multiple KSEs up and running.

>     In the past this has been a sticking point for KSE, and recently there
>     have been problems for libthr as well.  Give the threading goals of
>     (a) improved I/O latency, and (b) parallelism to see an improvement
>     over libc_r, SMP support is an important thing to know works, or is
>     close to working.  Do you guys have the hardware you need to do that
>     testing?

I don't, but David seems to.  I'm not sure that having an SMP box
would help me currently because there are other things I can work
on (see all of the above).  At some point, though, I should probably
ask donations@ for one.

> (2) Do we have any early performance measurements (quantitative or
>     otherwise) the compare for gains/losses vs. libc_r for libpthread? 
>     I.e., comparison of context switch times, throughput for some pthread
>     application we like (dumb mysql test), etc?

No, we (or at least me) are extremely busy trying to get other
things fixed.  This is certainly an area in which others are welcome
to help.  We could also use some testers to find bugs, especially if
they can submit sample programs to demonstrate them, or even
better -- patches to fix them :-)

> Also, any luck getting KSE context management support up and running on
> non-i386?

No, I don't think I currently have any cycles available.  I'm
not sure about David, and Julian seems to be busy.  Anyone
from sparc@, alpha@, ia64@ are welcome to pick up the reigns.

Dan Eischen

More information about the cvs-all mailing list