AW: AW: Need SMP access (FreeBSD port of SAPDB aka MaxDB (fwd))

[Daniel Eischen]

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