Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Oct 2003 14:41:26 -0400 (EDT)
From:      Daniel Eischen <eischen@vigrid.com>
To:        Kai Mosebach <kai.mosebach@freshx.de>
Cc:        threads@freebsd.org
Subject:   Re: AW: AW: Need SMP access (FreeBSD port of SAPDB aka MaxDB (fwd))
Message-ID:  <Pine.GSO.4.10.10310021436400.28331-100000@pcnet5.pcnet.com>
In-Reply-To: <000201c3890a$98b96130$0400a8c0@dread>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2 Oct 2003, Kai Mosebach wrote:

> > > Hi,
> > >
> > > We can do most of the single processor stuff on our own test
> machines,
> > > but we do not know yet, how it behaves (or even if it behaves) on a
> SMP
> > > using kse. The more important aspect to us though is, that some of
> the
> > > threading specialists can take a look on some behaviours and
> > > misbehaviours, and mabe tell us whether its from the code, nor from
> the
> > > kse implementation ;).
> > 
> > Well, just get it working under FreeBSD with native threading
> > (KSE) and modify the port to respect PTHREAD_LIBS instead of
> > linuxthreads.  Others can help you test on SMP, but in theory
> > it should behave no differently than on UP.  You can simulate
> > KSE/SMP on a UP system by setting the following sysctls:
> 
> Native KSE threading is already done. Some problems occurred though,
> which yet seem to be scheduling problems in the threading (A complete
> database backup runs, but does not responds correctly, when finished.).

Can you tell me what you mean "does not responds correctly".  Are
you forking and waiting for SIGCHLD or something?

> Question from a SAP Developer was, if there are there ways for
> "scheduling checks" in the lib ?

You can define DEBUG_THREAD_KERN (in libpthread/thread/thr_kern.c)
and DEBUG_SIGNAL (in libpthread/thread/thr_sig.c), but that will
give you a lot of output and may end up screwing other things
up.  You can also send the process a SIGINFO and it will dump
the threads and their states to /tmp/pthread.dump.pid.n.

> > 
> > 	kern.threads.debug: 0 -> 1
> > 	kern.threads.virtual_cpu: 1 -> 2
> > 
> > Let us know if you have any problems.
> 
> I will try that ...

Make sure your libpthread is up to date.  There have been a few
fixes in the last few weeks.

-- 
Dan Eischen



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10310021436400.28331-100000>