From owner-cvs-all Mon Feb 19 1:41: 5 2001 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D2BEE37B401; Mon, 19 Feb 2001 01:40:58 -0800 (PST) Received: (from bde@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f1J9ewj89963; Mon, 19 Feb 2001 01:40:58 -0800 (PST) (envelope-from bde) Message-Id: <200102190940.f1J9ewj89963@freefall.freebsd.org> From: Bruce Evans Date: Mon, 19 Feb 2001 01:40:58 -0800 (PST) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern kern_sig.c X-FreeBSD-CVS-Branch: HEAD Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG bde 2001/02/19 01:40:58 PST Modified files: sys/kern kern_sig.c Log: Fixed a longstanding latency bug in signal delivery. When a signal is sent to a process, psignal() needs to schedule an AST for the process if the process is runnable, not just if it is current, so that pending signals get checked for on the next return of the process to user mode. This wasn't practical until recently because the AST flag was per-cpu so setting it for a non-current process would usually just cause a bogus AST for the current process. For non-current processes looping in user mode, it took accidental (?) magic to deliver signals at all. Signals were usually delivered late as a side effect of rescheduling (need_resched() sets astpending, etc.). In pre-SMPng, delivery was delayed by at most 1 quantum (the need_resched() call in roundrobin() is certain to occur within 1 quantum for looping processes). In -current, things are complicated by normal interrupt handlers being threads. Missing handling of the complications makes roundrobin() a bogus no-op, but preemptive scheduling sort of works anyway due to even larger bogons elsewhere. Revision Changes Path 1.109 +3 -7 src/sys/kern/kern_sig.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message