Date: Fri, 21 Sep 2001 18:26:11 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern sys_generic.c Message-ID: <XFMail.010921182611.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0109211658090.37053-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-Sep-01 Julian Elischer wrote: > You are right.. I meant p_sflag, > and in that context, The signal flag did move. > It is however the only one.. luckily.. > > It does suggest to me that maybe it was mislocated origially :-) > > I never 100% understood that flag... Nah, what determines a per-thrad flag and what determines a scheduler flag aren't necessarily the same thing, so it was right for it to be in p_flag (it's not scheduler related very much) and it was right for it to be in td_flag (definitely a thread property). I think that TDF_SELECT basically is used so that selrecord() won't try to wakeup a process during the active scan in select() and poll() and after we finish the scan we check that flag to see if any events were found that should trigger an immediate return. I'll tackle that flag when I get to it in my second sweep of proc locking. It will probably stay as it is, but if I always lock the proc as well as sched_lock when writing to the flag, than I can get away with only locking the proc when testing that flag to avoid sched_lock in a few cases. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010921182611.jhb>