| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the system queue header file fully usable within C++ programs by
adding macros to define class lists.
This change is backwards compatible for all use within C and C++
programs. Only C++ programs will have added support to use the queue
macros within classes. Previously the queue macros could only be used
within structures.
The queue.3 manual page has been updated to describe the new
functionality and some alphabetic sorting has been done while
at it.
Differential Revision: https://reviews.freebsd.org/D2745
PR: 200827 (exp-run)
|
|
|
|
|
| |
Provide an unambiguous description of the potential hazard in calling
pthread_setspecific(3) from a key destructor.
|
|
|
|
| |
Added description of POSIX-specified behavior when invoked on a key from within that key's destructor.
|
|
|
|
| |
Make wait6(2), waitid(3) and ppoll(2) cancellation points.
|
|
|
|
|
|
|
|
| |
r281605:
Fix a minor function definition inconsistancy.
r281768:
Bump doc date missed in r281605.
|
|
|
|
| |
Formatting changes to the pthread_testcancel(3).
|
|
|
|
| |
Make kevent(2) a cancellation point.
|
|
|
|
| |
Provide individual prototype and generate macros for the red-black tree.
|
|
|
|
|
|
|
|
|
| |
Clarify that pthread_cleanup_push()/pop() are implemented as macros that
create a new code block and thus must be balanced at the same lexical
scope. (This is also a requirement in POSIX.)
PR: 194280
Submitted by: dr2867.business@pacbell.net
|
|
|
|
|
|
|
| |
Clarify descriptions of pthread_cond_wait() and pthread_cond_timedwait()
Submitted by: Malcolm Douglas via freebsd-doc
Reviewed by: jhb
|
|
|
|
|
|
|
|
| |
- Update a few places to account for va_copy().
- Create a separate 'return values' section and move some statements about
return values to that section.
- Note that each invocation of va_start() and va_copy() must be paired with
va_end() in the same function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
optionally start the traversal from a previously found element by passing the
element in as "var". Passing a NULL "var" retains the same semantics as the
regular FOREACH macros.
Kudos to phk for suggesting the "FROM" suffix instead of my original proposal.
Reviewed by: jhb (previous version), rpaulo
MFC after: 1 week
|
|
|
|
|
| |
This should be a fairly complete list of cancellation points in libc, libthr
and librt, including standard as well as non-standard functions.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Also fix cpu_getaffinity(2) document title.
PR: 176317
Submitted by: brucec
|
|
|
|
|
| |
Submitted by: Benedikt Steinbusch (benedikt.steinbusch@googlemail.com)
Approved by: sbruno (mentor)
|
| |
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
| |
Describe SI_LWP as being generated by pthread_kill() because thr_kill() is
a private undocumented function.
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
| |
PR: docs/171624
Submitted by: bdrewery
Approved by: gabor
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Regular LISTs have been implemented in such a way that the prev-pointer
does not point to the previous element, but to the next-pointer stored
in the previous element. This is done to simplify LIST_REMOVE(). This
macro can be implemented without knowing the address of the list head.
Unfortunately this makes it harder to implement LIST_PREV(), which is
why this macro was never here. Still, it is possible to implement this
macro. If the prev-pointer points to the list head, we return NULL.
Otherwise we simply subtract the offset of the prev-pointer within the
structure.
It's not as efficient as traversing forward of course, but in practice
it shouldn't be that bad. In almost all use cases, people will want to
compare the value returned by LIST_PREV() against NULL, so an optimizing
compiler will not emit code that does more branching than TAILQs.
While there, make the code a bit more readable by introducing
__member2struct(). This makes STAILQ_LAST() far more readable.
MFC after: 1 month
|
| |
|
| |
|
|
|
|
|
|
| |
PR: 167734
Submitted by: Nobuyuki Koganemaru (kogane!jp.freebsd.org)
MFC after: 3 days
|
|
|
|
|
|
|
| |
quotation. Also make sure we have the same amount of columns in each row as
the number of columns we specify in the head arguments.
Reviewed by: brueffer
|
|
|
|
|
|
|
| |
Disussed with: gavin
No objection from: doc
Approved by: joel
MFC after: 3 days
|
| |
|
| |
|
|
|
|
|
|
| |
Submitted by: amdmi3
PR: 165431
MFC after: 1 week
|
|
|
|
| |
Obtained from: OpenBSD
|
|
|
|
|
|
|
|
| |
This switches us to using -isoC-2011 as the symbol name which is used by
groff and mdocml. It follows the change to 4 digit years as done with
IEEE Std 1003 post-1999.
MFC after: 2 weeks (groff changes only)
|
|
|
|
|
|
|
|
|
|
|
|
| |
The macro construction used now, is almost identical to the code
provided in C11 proposal N1404. This new version doesn't seem to
introduce any regressions according to the regression test in tools/,
but still seems to malfunction with Clang on certain aspects.
The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7,
it also works when __generic() is implemented on top of _Generic().
Discussed with: stefanf
|
| |
|
|
|
|
| |
While sorting the MLINKS by name, I forgot to re-add it.
|
| |
|
|
|
|
|
|
| |
text to the remaining description.
Approved by: re
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
| |
Also place STAILQ_REMOVE_HEAD in alphabetical order. Lastly, document
the _SWAP macros.
PR: kern/143033
MFC after: 1 week
|
|
|
|
| |
Approved by: davidxu
|
|
|
|
| |
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
It has also been included within the feature lists to which it is relevant.
Submitted by: tobez
MFC after: 1 week
|
|
|
|
|
|
|
| |
one might expect. (These functions have already been deprecated for
many years.)
PR: 133583
|
|
|
|
| |
EINVAL error cases.
|
|
|
|
| |
They have no effect when coming in pairs, or before .Bl/.Bd
|
| |
|