From owner-freebsd-hackers  Mon Dec  1 21:07:06 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA28709
          for hackers-outgoing; Mon, 1 Dec 1997 21:07:06 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA28688
          for <hackers@freebsd.org>; Mon, 1 Dec 1997 21:06:59 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
          by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id VAA01819;
          Mon, 1 Dec 1997 21:05:34 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Message-Id: <199712020505.VAA01819@rah.star-gate.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Terry Lambert <tlambert@primenet.com>
cc: cmott@srv.net (Charles Mott), hasty@netcom.com, hackers@freebsd.org
Subject: Re: ftp server on ftp.cdrom.com 
In-reply-to: Your message of "Tue, 02 Dec 1997 01:02:15 GMT."
             <199712020102.SAA26394@usr07.primenet.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 01 Dec 1997 21:05:33 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > Initially, I was thinking that port 20 data transfers (as opposed to port
> > 21 control traffic) had to be either separate processes or threads, but
> > now I think you are right -- everything could be done by a synchronous
> > state machine in a single user process, but this might be inefficient. 
> 
> Unless you used aioread/aiowrite/aiowait/aiocancel from John Dyson's
> /sys/kern/vfs_aio.c in -current.  Then you could overlap I/O.
> 
> The distinction to be made here is that async I/O and call-conversion
> threading mechanisms do not scale on SMP (ie: adding more processors
> does not make the work get done any more swiftly).  The main drawback
> to user space threading mechanisms (like pthreads and user context
> management with aio and/or "sigsched", etc.) is SMP and/or cluser
> scalability.

You are right and that depends on how the I/O subsystem is architected
or how low level i/o calls are routed thru the system.

For an SMP architecture one could implement multiple state machine
servers.

	Amancio