Date: Wed, 15 Sep 1999 16:31:09 +0000 (GMT) From: Alfred Perlstein <bright@wintelcom.net> To: Christopher Sedore <cmsedore@mailbox.syr.edu> Cc: Jayson Nordwick <nordwick@scam.xcf.berkeley.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: High Performance I/O (more) Message-ID: <Pine.BSF.4.05.9909151621520.6392-100000@fw.wintelcom.net> In-Reply-To: <Pine.SOL.4.10.9909151235280.1425-100000@rodan.syr.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 Sep 1999, Christopher Sedore wrote: > My ideas for this are a little different than what I've seen proposed thus > far, more along the lines of creating something that acts as both an event > queue and a IOCP. Ideally this would be a descriptor that could be shared > across processes (or threads), and could be accessed using read(). I > don't much care for the suggestion that threads ought to have an event > queue of their own--rather if you want a per-thread completion > notification, simply create a descriptor for each thread that needs this > function. What ever is created, it should be sufficiently extensible to > allow for all the events we can imagine now, as well as being flexible for > future enhancement. (FWIW, I've also been thinking that I might like to > be able to submit aio requests by write()ing said descriptor. Just a > thought.) I thought it'd be very useful to be able to give the kernel a pointer to a pollfd struct in your (userland) address space, when events occur SIGIO (or maybe some other signal?) is posted to the process after updating the process's pollfd. This makes queing not nessesary because if a signal is 'lost' somehow the pollfd is still updated, it also reduces the amount of syscalls needed by at least one. From what I understand your methodology of async IO involves this type of cycle: syscall_register_descriptor -> SIGIO -> \ syscall_read_from_event_queue -> syscall_read/write/lock/etc Being able to register the pollfd allows for a minimal amount of memory overhead and one less syscall, infact it doesn't even require much of a new subsystem: syscall_register_pollfd -> SIGIO -> kernel to userland write \ userland_pollscan -> syscal_read/write/lock/etc You would have to have a refresh the kernel pollfd array if what you were interested in changed. How does this sound to you? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9909151621520.6392-100000>