Date: Tue, 27 May 1997 13:31:17 -0400 (EDT) From: Christopher Sedore <cmsedore@mailbox.syr.edu> To: Ruslan Shevchenko <rssh@cki.ipri.kiev.ua> Cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff Message-ID: <Pine.SOL.3.95.970527132125.11245A-100000@gamera.syr.edu> In-Reply-To: <338AF74F.2E3D@cki.ipri.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.95.970527132125.11245A-100000>