Re: new library: libisc
In article [EMAIL PROTECTED], Archie Cobbs [EMAIL PROTECTED] wrote: Absent violent rejection, I'd like to add the ISC utility library to the FreeBSD build. If you're not familiar, check out the man pages /usr/src/contrib/bind/lib/isc/*.mdoc. There are several useful utilities in there. The main thing I'm interested in is the event library, but there is other useful stuff in there too. Yes please! This is something I've wanted to have in the system for a long time. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
In article
[EMAIL PROTECTED], Daniel
Eischen [EMAIL PROTECTED] wrote:
So far I read this as saying the sched_XXX functions operate on
processes, whereas the pthread_{set|get}schedparam functions operate
on threads.
Me too.
(4) When a running thread calls the sched_setparam() function,
the priority of the process specified in the function call is
modified to the priority specified by the param argument.
If the thread whose priority has been modified is a running
thread or is runnable, runnable thread [sic] it then becomes
the tail of the thread list for its new priority.
This contradicts itself and is where I think it is unclear. Where
does it state that the _threads_ priority is modified? It only
says that the process priority is modified. When it goes on to
say "If the thread whose priority has been modified...", it's
assuming something that was never stated as a requirement.
Agreed. I think they meant process, not thread. The whole section
has quite a few things I suspect are typos and/or editing errors.
(5) When a running thread calls the pthread_setschedparam()
function, the thread specified in the function call is
modified to the specified policy and the priority specified by
the param argument.
The above is a clearly stated requirement. If they had meant for
the threads priority to be changed by sched_setparam(), then it
should have been stated just as it has been above (5).
(6) If a thread whose policy or priority has been modified is
a running thread or is runnable, runnable thread [sic] it then
becomes the tail of the thread list for its new priority.
Unless it holds a priority protection or inheritence mutex, in
which case it gets added to the head of the thread list for its
new priority. This case is often forgotten (see 13.6.1.2).
I get the feeling they rushed this part into print after making a
lot of last-minute changes to it.
For this policy, valid priorities shall be within the range
returned by the function sched_get_priority_max() and
sched_get_priority_min() when SCHED_FIFO is provided as the
parameter.
So it seems clear that the same range of priorities shall apply to
individual threads as well as to processes. (SCHED_RR is similar in
these respects.)
For SCHED_FIFO and SCHED_RR, we don't have a problem because both
the threads library and kernel now agree that the range is 0..31.
SCHED_OTHER is a problem because the threads library treats
SCHED_OTHER as SCHED_RR with range 0..31. The kernel treats
SCHED_OTHER traditionally with range -20..20.
As long as the only problem area is SCHED_OTHER, we are arguably
OK. SCHED_OTHER is almost entirely implementation-defined; it can
do practically anything. More specifically, section 13.5.2.2 (the
detailed description of pthread_[sg]etschedparam) says:
The policy parameter may have the value SCHED_OTHER, SCHED_FIFO,
or SCHED_RR. The scheduling parameters for the SCHED_OTHER policy
are implementation defined. The SCHED_FIFO and SCHED_RR policies
shall have a single scheduling parameter sched_priority.
I think it would be slightly less surprising if our implementation of
SCHED_OTHER used thread priorities in the range -20..20 just the same
as processes. But in my opinion POSIX doesn't require that.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: I've just committed some changes to the threads library and would appreciate feedback from anyone running threaded applications. They include fixes that -stable could really use. This commit also implements zero system call thread context switching in the threads library. Switching between threads is now much faster than before this change. This sounds like great stuff! The range of valid priorities has also changed, perhaps requiring a library version bump. The range of valid priorities is not visible outside of the threads library. The only way it can be determined is through trial and error, so it _shouldn't_ be an issue. I thought you could get that information with sched_get_priority_min() and sched_get_priority_max(). Is that not the case? John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: The range of valid priorities has also changed, perhaps requiring a library version bump. The range of valid priorities is not visible outside of the threads library. The only way it can be determined is through trial and error, so it _shouldn't_ be an issue. I thought you could get that information with sched_get_priority_min() and sched_get_priority_max(). Is that not the case? Not really. Those return the kernels POSIX priority range for processes. Hmm, that's not how I interpret the POSIX spec. Here are some excerpts from section 13.2, "Scheduling Policies". That's in the chapter which describes all of the sched_XXX() functions. This model discusses only processor scheduling for runnable threads ... There is, conceptually, one thread list for each priority. Any runnable thread may be on any thread list. Multiple scheduling policies shall be provided. Each nonempty thread list is ordered, contains a head as one end of its order, and a tail as the other. The purpose of a scheduling policy is to define the allowable operations on this set of lists. Each process shall be controlled by an associated scheduling policy and priority. These parameters may be specified by explicit application execution of the sched_setscheduler() or sched_setparam() functions. Each thread shall be controlled by an associated scheduling policy and priority. These parameters may be specified by explicit application execution of the pthread_setschedparam() function. And then in the discussion of the SCHED_FIFO scheduling policy in section 13.2.1, it says: (4) When a running thread calls the sched_setparam() function, the priority of the process specified in the function call is modified to the priority specified by the param argument. If the thread whose priority has been modified is a running thread or is runnable, runnable thread [sic] it then becomes the tail of the thread list for its new priority. (5) When a running thread calls the pthread_setschedparam() function, the thread specified in the function call is modified to the specified policy and the priority specified by the param argument. (6) If a thread whose policy or priority has been modified is a running thread or is runnable, runnable thread [sic] it then becomes the tail of the thread list for its new priority. ... For this policy, valid priorities shall be within the range returned by the function sched_get_priority_max() and sched_get_priority_min() when SCHED_FIFO is provided as the parameter. So it seems clear that the same range of priorities shall apply to individual threads as well as to processes. (SCHED_RR is similar in these respects.) John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs servers load
In article [EMAIL PROTECTED], Wilko Bulte [EMAIL PROTECTED] wrote: Time to put the cvsup servers on the map with ICBM coordinates maybe? The US CVSup mirrors are listed by state in the FreeBSD Handbook at http://www.freebsd.org/handbook/cvsup.html#CVSUP-MIRRORS Physical location often doesn't mean much, though. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs servers load
In article [EMAIL PROTECTED], Dennis Glatting [EMAIL PROTECTED] wrote: Any running load information on the CVS servers available? Nope, sorry. I'd like to adjust my pointers to help spread the load. My current pointers, for myself and two clients, is cvsup3. My location: Redmond, Washington (across lake Sammamish from the Evil Empire) Often the newer (higher numbered) servers are less loaded than the older ones. CVSup9.FreeBSD.org is brand new and could handle a lot more clients. It's a fast machine and it's still sitting idle most of the time. Given where you live, you might want to try cvsup7, since it is located just across Lake Washington from you in the Westin building. If you're lucky, you might be able to get to it without having your packets travel halfway across the US and back. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
