From owner-freebsd-net Wed Jul 5 2:11:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from mail.pace.co.uk (mh.pace.co.uk [136.170.50.8]) by hub.freebsd.org (Postfix) with ESMTP id 49CB737B782 for ; Wed, 5 Jul 2000 02:11:23 -0700 (PDT) (envelope-from kbracey@pace.co.uk) Received: from admin-1.pace.co.uk (admin-1.cam.pace.co.uk [136.170.131.64]) by mail.pace.co.uk (8.9.1b+Sun/8.9.1) with ESMTP id KAA11762 for ; Wed, 5 Jul 2000 10:11:17 +0100 (BST) Received: from art-work.cam.pace.co.uk (art-work.cam.pace.co.uk [136.170.131.5]) by admin-1.pace.co.uk (8.9.1b+Sun/8.9.1) with ESMTP id KAA19926 for ; Wed, 5 Jul 2000 10:11:17 +0100 (BST) Received: from kbracey.cam.pace.co.uk (kbracey.cam.pace.co.uk [136.170.129.213]) by art-work.cam.pace.co.uk (8.9.3+Sun/8.9.1) with SMTP id KAA09230 for ; Wed, 5 Jul 2000 10:11:16 +0100 (BST) Date: Wed, 05 Jul 2000 10:02:02 +0100 From: Kevin Bracey To: freebsd-net@freebsd.org Subject: Re: Race condition in TCP connection drops? Message-ID: <2de442d949%kbracey@kbracey.cam.pace.co.uk> In-Reply-To: <200007041829.OAA22401@khavrinen.lcs.mit.edu> X-Organization: Pace Micro Technology plc, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200007041829.OAA22401@khavrinen.lcs.mit.edu> Garrett Wollman wrote: > < said: > > > This is totally reliable on our system, because the psignal mechanism is > > synchronous. Are there interlocks to prevent this happening on FreeBSD, or is > > it a race condition? > > On all BSD systems since time immemorial (and probably Bell Labs Unix > before that), signal delivery is asynchronous, and the kernel is > non-preemptible, so this is not possible. Thanks, I suspected it was something like that. A while back I tried changing psignal call to mark per-socket signal requirements in a bitfield, and then send them on exit from the network stack, as I was somewhat suspicious of this sort of problem occurring. Unfortunately that caused problems when the system was under high load (MPEG 2 video streaming in this case) - data would come in in spurts as fast as the stack could deal with it, so the network stack would remain looping through the interrupt queue in the packet input routine without sending any signals, so the socket buffer would overflow because the MPEG software wasn't getting a chance to read it. I'll have a go at doing something like that again, but with a few more points where signals can be triggered (eg each time round the input loop). Also, as far as I can see there's no need for soisdisconnected() to be called before in_pcbdetach() - if that's right, swapping those statements would be a very easy fix for my particular problem. -- Kevin Bracey, Principal Software Engineer Pace Micro Technology plc Tel: +44 (0) 1223 518566 645 Newmarket Road Fax: +44 (0) 1223 518526 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message