From owner-freebsd-current  Tue Apr 13 14:51:28 1999
Delivered-To: freebsd-current@freebsd.org
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
	by hub.freebsd.org (Postfix) with ESMTP id 1514314CBE
	for <current@FreeBSD.ORG>; Tue, 13 Apr 1999 14:51:24 -0700 (PDT)
	(envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id RAA13399;
	Tue, 13 Apr 1999 17:48:31 -0400 (EDT)
Date: Tue, 13 Apr 1999 17:48:31 -0400 (EDT)
From: Daniel Eischen <eischen@vigrid.com>
Message-Id: <199904132148.RAA13399@pcnet1.pcnet.com>
To: jdp@polstra.com, mi@aldan.algebra.com
Subject: Re: cvsup
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

John Polstra wrote:
> Correct.  I have not tried to analyze where the delays come from.
> But I do have a guess.
> 
> CVSup uses user-level threads.  If a thread gets blocked waiting for
> network I/O, the thread scheduler can run a different thread while it
> is waiting.  A subsequent call to select() will inform the scheduler
> when the I/O can be resumed.
> 
> But that isn't possible for disk I/O.  If you call read() or write()
> on a disk file, it never returns EAGAIN.  It always blocks in the
> kernel, non-interruptible by signals.  When that happens, the process
> is blocked and it can't run any other threads or do anything else
> at all until the read/write call has completed.  Since CVSup is so
> disk-intensive, I suspect it is wasting a lot of time blocked in those
> calls.  An interested person could probably confirm or deny that using
> ktrace.
>

Does Modula-3 use libc_r, or does it have it's own user thread support?

The recent set of commits to libc_r changed the thread scheduling
mechanism to use ITIMER_PROF instead of ITIMER_VIRTUAL.  This was
to allow for fairer scheduling with I/O bound threads.

Dan Eischen
eischen@vigrid.com


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