From owner-freebsd-chat Fri Oct 27 17:23:36 2000 Delivered-To: freebsd-chat@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 4E25E37B4C5 for ; Fri, 27 Oct 2000 17:23:33 -0700 (PDT) Received: from alumni.caltech.edu ([63.201.176.178]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G3400E7X640HL@mta5.snfc21.pbi.net> for chat@FreeBSD.ORG; Fri, 27 Oct 2000 17:16:49 -0700 (PDT) Date: Fri, 27 Oct 2000 17:24:56 -0700 From: Dan Kegel Subject: Re: kqueue microbenchmark results To: Terry Lambert Cc: Alan Cox , Jonathan Lemon , Gideon Glass , Simon Kirby , chat@FreeBSD.ORG, linux-kernel@vger.kernel.org Reply-To: dank@alumni.caltech.edu Message-id: <39FA1CD8.6C6ABAEE@alumni.caltech.edu> MIME-version: 1.0 X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200010272308.QAA29462@usr01.primenet.com> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert wrote: > > > > Which is precisely why you need to know where in the chain of events this > > > happened. Otherwise if I see > > > 'read on fd 5' > > > 'read on fd 5' > > > How do I know which read is for which fd in the multithreaded case > > > > That can't happen, can it? Let's say the following happens: > > close(5) > > accept() = 5 > > call kevent() and rebind fd 5 > > The 'close(5)' would remove the old fd 5 events. Therefore, > > any fd 5 events you see returned from kevent are for the new fd 5. > > Strictly speaking, it can happen in two cases: > > 1) single acceptor thread, multiple worker threads > 2) multiple anonymous "work to do" threads > > In both these cases, the incoming requests from a client are > given to any thread, rather than a particular thread. > > In the first case, we can have (id:executer order:event): > > 1:1:open 5 > 2:2:read 5 > 3:4:read 5 > 2:3:close 5 > > If thread 2 processes the close event before thread 3 processes > the read event, then when thread 3 attempts procssing, it will > fail. You're not talking about kqueue() / kevent() here, are you? With that interface, thread 2 would not see a close event; instead, the other events for fd 5 would vanish from the queue. If you were indeed talking about kqueue() / kevent(), please flesh out the example a bit more, showing who calls kevent(). (A race that *can* happen is fd 5 could be closed by another thread after a 'read 5' event is pulled from the event queue and before it is processed, but that could happen with any readiness notification API at all.) - Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message