Date: Mon, 1 Dec 1997 21:00:27 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: tlambert@primenet.com (Terry Lambert) Cc: cmott@srv.net, hasty@netcom.com, hackers@freebsd.org Subject: Re: ftp server on ftp.cdrom.com Message-ID: <199712020200.VAA08364@dyson.iquest.net> In-Reply-To: <199712020102.SAA26394@usr07.primenet.com> from Terry Lambert at "Dec 2, 97 01:02:15 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert said: > > 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. > > This should, however, work as well as "ddd" or "team". > Actually, I have been thinking about carrying the code into a clean abstraction. Right now, I have a "shortcut" for VCHR files (physio type I/O), and it could also be extended to sockets, pipes, etc. At that point, it seems that a switch-type capability would be neat. I know that I could do sockets and pipes pretty quickly. Our AIO physio mechanism is actually about as efficient as it can be (plus/minus some LL optimizations.) -- John dyson@freebsd.org jdyson@nc.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712020200.VAA08364>