From owner-freebsd-hackers Tue May 27 10:31:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA23825 for hackers-outgoing; Tue, 27 May 1997 10:31:53 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA23820 for ; Tue, 27 May 1997 10:31:51 -0700 (PDT) Received: from gamera.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.45923FF0@mailer.syr.edu>; Tue, 27 May 1997 13:31:24 -0400 Received: from localhost (cmsedore@localhost) by gamera.syr.edu (8.8.5/8.8.5) with SMTP id NAA13132; Tue, 27 May 1997 13:31:18 -0400 (EDT) X-Authentication-Warning: gamera.syr.edu: cmsedore owned process doing -bs Date: Tue, 27 May 1997 13:31:17 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@gamera.syr.edu To: Ruslan Shevchenko cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: <338AF74F.2E3D@cki.ipri.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Ruslan Shevchenko wrote: > Christopher Sedore wrote: > > > > I've been thinking about implementing some async socket handling code and > > am wondering if someone else is doing this or has done it. I've been > > thinking about two different approaches: > > > > 1. Creating a new ioctl set and a few syscalls to allow you to > > associate a socket with something like an NT I/O completion port. This > > would allow you to associate a socket descriptor with a queue and each > > time the socket's status changed (via sorwakeup or sowwakeup) I'd post an > > entry into the queue. The idea is that rather than using select() and > > then searching through a list of descriptors, you could just read them off > > one (or many) at a time and do I/O on the appropriate descriptors. This > > seems to me to be more efficient than select(). > > What process must do, if it queue is emty ? --- if wait, > it's simular to select call. > In principle it can be option in general net library. Well, there should be an option to wait or timeout (like select). The principal difference is that you don't have to go through all your descriptors to determine which ones are ready for I/O. If I have say 800-900 descriptors this might be a bit costly in terms of performance on a per-transaction basis. > > > > 2. Implementing general async I/O for sockets. Then, rather than (or > > perhaps in addition to) the above functionality, you could use the queue > > to hold results of async operations. > > > > I've also thought of adding a call like NT's TransmitFile() (single call > > file transfer). > > > > why syscoll ? You think, taht it is systel-level stuff ? > It can be do in extra library. It sure could, but you end up with many more system calls, and it is not async. The real advantage to a call like TransmitFile() is that you can send an entire file (or a range of a file) with a single system call, and you can do it async. This means that you can more efficiently implement things like FTP servers, Web servers, pop servers, etc. -Chris