different from what has been offered in libc_r (the one spotted in the
original PR which is found in libthr has already been removed by David's
commit, which is rev. 1.44 of lib/libthr/thread/thr_private.h):
- Use POSIX standard prototype for ttyname_r, which is,
int ttyname_r(int, char *, size_t);
Instead of:
char *ttyname_r(int, char *, size_t);
This is to conform IEEE Std 1003.1, 2004 Edition [1].
- Since we need to use standard errno for return code, include
errno.h in ttyname.c
- Update ttyname(3) implementation according to reflect the API
change.
- Document new ttyname_r(3) behavior
- Since we already make use of a thread local storage for
ttyname(3), remove the BUGS section.
- Remove conflicting ttyname_r related declarations found in libc_r.
Hopefully this change should not have changed the API/ABI, as the ttyname_r
symbol was never introduced before the last unistd.h change which happens a
couple of days before.
[1] http://www.opengroup.org/onlinepubs/009695399/functions/ttyname.html
Requested by: Tom McLaughlin <tmclaugh sdf lonestar org>
Through PR: threads/76938
Patched by: Craig Rodrigues <rodrigc crodrigues org> (with minor changes)
Prompted by: mezz@
These files had tags after teh copyright notice,
inside the comment block (incorrect, removed),
and outside the comment block (correct).
Approved by: rwatson (mentor)
thread library for i386, amd64, and ia64. For alpha
and sparc64 the library is not changed and remains libkse,
and links are installed so that libpthread -> libc_r.
The gcc -pthread option will be changed in a separate
commit so that it links to -lpthread instead of -lc_r.
Approved by: re@
we can end up with some threads with a non-16-byte-aligned stack. This
causes some interesting side effects, including general protection
faults leading to a SIGBUS when doing floating point or varargs. This
should be just a verbose NOP for the other platforms.
Approved by: re (scottl)
don't allow it at the moment, the correct thing to do is try again.
Otherwise, libthr would fail this test because it doesn't allow
an unlimited number of concurrent threads per application.
an excessive close() on one of these descriptors would cause
a memory for this descriptor to be allocated in the internal
descriptor table. When this descriptor gets used again, e.g.
through the call to open() or socket(), the descriptor would
be erroneously left in the blocking mode, and the whole
application would get stuck on a blocking operation, e.g.,
in accept(2).
Prevent this bug from happening by disallowing close() against
non-active descriptors (return -1 and set errno to EBADF in
this case).
Reviewed by: deischen
Approved by: re (scottl)
libthr. No changes were made to libpthread by request of deischen,
who will soon commit a real implementation for that library.
PR: standards/50848
Submitted by: Sergey A. Osokin <osa@freebsd.org.ru>
MFC after: 1 week
more complicated things than just setting the lock to 0.
- Implement stubs for this function in libc and the two threading libraries
that are currently in the tree.
not save (restore) the global pointer (GP) in the jmpbuf in setjmp
(longjmp) because it's not needed in general. GP is considered a
scratch register at callsites and hence is always restored after a
call (when it's possible that the call resolves to a symbol in a
different loadmodule; otherwise GP does not have to be saved and
restored at all), including calls to setjmp/longjmp. There's just
one problem with this now that we use setjmp/longjmp for context
switching: A new context must have GP defined properly for the
thread's entry point. This means that we need to put GP in the
jmpbuf and consequently that we have to restore is in longjmp.
This automaticly requires us to save it as well.
When setjmp/longjmp isn't used for context switching, this can be
reverted again.
