From owner-freebsd-hackers  Wed Jan 17 11:24:39 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from bulwark.switch.com (bulwark.switch.com [206.181.77.34])
	by hub.freebsd.org (Postfix) with SMTP id 8F6D837B402
	for <freebsd-hackers@FreeBSD.org>; Wed, 17 Jan 2001 11:24:11 -0800 (PST)
Received: by bulwark.switch.com; id OAA10191; Wed, 17 Jan 2001 14:24:11 -0500
Received: from dhcp103-172-16-3.switch.com(172.16.3.122) by bulwark.switch.com via smap (V5.5)
	id xma010173; Wed, 17 Jan 01 14:23:53 -0500
Received: (from breaker@localhost)
	by dhcp103-172-16-3.switch.com (8.11.1/8.11.1) id f0HJNhE01301
	for freebsd-hackers@FreeBSD.org; Wed, 17 Jan 2001 14:23:43 -0500 (EST)
	(envelope-from breaker)
Date: Wed, 17 Jan 2001 14:23:43 -0500
From: Trent Nelson <tpnelson@switch.com>
To: freebsd-hackers@FreeBSD.org
Subject: Network I/O multiplexing questions.
Message-ID: <20010117142343.A1144@dhcp103-172-16-3.switch.com>
Mail-Followup-To: Trent Nelson <tpnelson@switch.com>,
	freebsd-hackers@FreeBSD.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

 1. Is there any performance/efficiency gained when read and write
    operations on multiple sockets are grouped together? That is, after
    the I/O multiplexer function returns (i.e. select/poll/kevent), all
    read operations on sockets are done together (say, encapsulated by
    a thread, perhaps) and likewise for write operations.

    I'm looking into writing something that uses the reply from kevent()
    to construct independent lists of read/write/error operations
    pending on multiple sockets. Some sort of executable entity
    (event-thread, state-thread, pthread, etc) will be responsible for
    processing the pending events and I figured the best performance
    would be gained if each execution stream is solely responsible for
    *only* doing read/write operations. Pthreads probably aren't a good
    example of a scheduleable entity given their scheduling criteria
    isn't predictable.

 2. Does "The Design and Implementation of the 4.4BSD Operating System"
    deal with how send/recv operations take place from receiving the
    data from the network interface, traversing the protocol hierarchy
    and eventually passing into user space? Is the text's coverage of
    this outdated in any way?

 3. What conditions, if any, are used to deem whether a read or write
    to a socket will block? Is there any quick and efficient way of
    doing this in userspace? I'm assuming it has something to do with
    the hi/lo watermarks of a socket and its associated I/O buffer. 

    Can anyone point me to instances of kernel source code where a check
    is made to see if a socket will block?

 4. Currently, if a process blocks on network I/O, is it immediately
    switched out of execution by the scheduler? 

 5. Has anyone taken a look at the State-Threads API proposed by SGI?
    Has anyone considered adding support for our kevent/kqueue multi-
    plexing method in addition to the select/poll methods offered?

        (http://oss.sgi.com/projects/state-threads/)

    Thanks in advance.

    Regards,

        Trent.

-- 
Trent Nelson - Software Engineer - tpnelson@switch.com
    "A man with unlimited enthusiasm can achieve 
        almost anything." --unknown



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message