As Garrett points out,
It is no more a debugging interface than setproctitle(3), and has not
been since the name started getting stuffed into the kernel. This
statement may have made sense when the name was only visible in thread
state dumps and the debugger.
PR: threads/158815
Submitted by: wollman@
calling thread's unique integral ID, which is similar to AIX function of
the same name. Bump __FreeBSD_version to note its introduction.
Reviewed by: kib
Note: clock accepts CLOCK_VIRTUAL and CLOCK_PROF too, but this seems broken
as it simply waits for the difference of the current and given value of the
clock as if it were CLOCK_MONOTONIC. So document only CLOCK_REALTIME and
CLOCK_MONOTONIC as allowed.
MFC after: 1 week
Although groff_mdoc(7) gives another impression, this is the ordering
most widely used and also required by mdocml/mandoc.
Reviewed by: ru
Approved by: philip, ed (mentors)
Last year I added SLIST_REMOVE_NEXT and STAILQ_REMOVE_NEXT, to remove
entries behind an element in the list, using O(1) time. I recently
discovered NetBSD also has a similar macro, called SLIST_REMOVE_AFTER.
In my opinion this approach is a lot better:
- It doesn't have the unused first argument of the list pointer. I added
this, mainly because OpenBSD also had it.
- The _AFTER suffix makes a lot more sense, because it is related to
SLIST_INSERT_AFTER. _NEXT is only used to iterate through the list.
The reason why I want to rename this now, is to make sure we don't
release a major version with the badly named macros.
- Document the minor(3), major(3) and makedev(3) macro's. They also
apply to umajor() and uminor() in the kernel, but hopefully we'll sort
that out one day.
- Briefly dev2unit() inside the make_dev(9) manual page, since this is
now the preferred macro to obtain character device unit numbers inside
the kernel.
- Remove the device_ids(9) manual page. It contains highly inaccurate
information, such as a description of the nonexistent major().
Even though single linked lists allow items to be removed at constant time
(when the previous element is known), the queue macro's don't allow this.
Implement new REMOVE_NEXT() macro's. Because the REMOVE() macro's also
contain the same code, make it call REMOVE_NEXT().
The OpenBSD version of SLIST_REMOVE_NEXT() needs a reference to the list
head, even though it is unused. We'd better mimic this. The STAILQ version
also needs a reference to the list. This means the prototypes of both
macro's are the same.
Approved by: philip (mentor)
PR: kern/121117
the mutex locked. Also tweak the wording to make it more consistant
between pthread_cond_wait and pthread_cond_tiedwait.
Confirmed with the opengroup's web site that this is a valid return
value. Wording used specifically not that of opengroup's online man
pages.
MFC After: 1 week
