From owner-freebsd-current  Thu Oct 29 13:13:54 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA23562
          for freebsd-current-outgoing; Thu, 29 Oct 1998 13:13:54 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA23544
          for <current@FreeBSD.ORG>; Thu, 29 Oct 1998 13:13:51 -0800 (PST)
          (envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id QAA19289;
	Thu, 29 Oct 1998 16:13:44 -0500 (EST)
Date: Thu, 29 Oct 1998 16:13:44 -0500 (EST)
From: Daniel Eischen <eischen@vigrid.com>
Message-Id: <199810292113.QAA19289@pcnet1.pcnet.com>
To: eischen@vigrid.com, info@highwind.com
Subject: Re: Thread Scheduler bug
Cc: current@FreeBSD.ORG, lists@tar.com
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>    > Possibly the VTALRM timer measures only time spent in user mode
>    > and not in kernel mode.  This heavy I/O takes place almost entirely
>    > in kernel mode and it is the only process running.  Therefore, very
>    > little user time is being accumulated.  
>    > 
>    > Possibly it you waited long enough, you'd still get the SIGVTALRM.
>    > If you add some user mode processing to the thread, you'll see
>    > the SIGVTALRM sooner.
> 
>    Yeah, I just figured this out (should pay closer attention to
>    the man pages).  Seems like the profiling timer would be closer
>    to what we'd want (not to say the threads library should use
>    the profiling timer).  A quick hack to replace occurrences of
>    SIGVTALRM with SIGPROF in the threads library seems to make
>    the test program work more correctly.
> 
> Interesting analysis. This seems to be a very NASTY problem.  If you
> have a collection of threads that spend a lot of time in system space,
> you can REALLY starve other threads. I can't imagine that this is a
> rare occurance.
> 
> Is using SIGPROF a viable alternative? Sounds a bit drastic.

I doubt it, as it would probably break POSIX semantics.  Threaded
applications then wouldn't be able to use SIGPROF.

A new signal or two, used only for the threads library would
be better.  I think Solaris uses a set of signals reserved just
for the threads library.  I think we're already max'd out with
signals though.

Is there any intention of allowing more than 32 signals?

Dan Eischen
eischen@vigrid.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message