[quagga-dev 7443] Re: (no subject)

Joakim Tjernlund joakim.tjernlund at transmode.se
Mon Nov 30 22:35:12 GMT 2009


Stephen Hemminger <shemminger at vyatta.com> wrote on 30/11/2009 20:43:51:
>
> On Mon, 30 Nov 2009 19:22:09 +0100
> Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
>
> > >
> > > On 30/11/2009 17:21, Joakim Tjernlund wrote:
> > > > linux 2.4 is still in use today because it is much smaller.
> > >
> > > Does the sort of glibc that you would use on a linux 2.4 support pthreads?
> >
> > Yes, but not NPTL
> >
> > >
> > > let me rephrase: does it support pthreads in a way which is bug-fix
> > > compatible with current versions of glibc or other libcs which are in use
> > > on more modern versions of linux?
> > >
> > > As another important issue to add to Greg's questions: how inter-compatible
> > > are the various pthread implementations used by the various operating
> > > systems that quagga supports?
> >
> > No idea, but as far as MONOTONIC_CLOCK goes, one should use times(2) when it
> > is missing.
> >
> > Threads is different issue, I don't think anyone wants to use pthreads on older
> > linux so no need to try. Just make sure the current "threads" still works after
> > you have added NPTL support.
> >
>
> Unfortunately, pthread mutex and locking primitives are slow. That is why almost
> all the databases end up rolling their own. Part of the problem is the glibc clash
> between being portable and being fast.
>
> What is the proposed design for using threads? I am concerned that if it just changes
> the bottleneck from being a single thread, to having a single lock there will be
> little performance gain.

Yes, I am not convinced either. What might work though is to make each daemon
a thread(zebra, bgp, ospf etc.). However, I do think there is much to do to
better the performance within the current framework.

  Jocke




More information about the Quagga-dev mailing list