Commit Graph

15 Commits

Author SHA1 Message Date
Yi Kong 32bc0fcf69 Modernize codebase by replacing NULL with nullptr
Fixes -Wzero-as-null-pointer-constant warning.

Test: m
Bug: 68236239
Change-Id: I5b4123bc6709641315120a191e36cc57541349b2
2018-08-02 18:09:44 -07:00
Elliott Hughes 48a69742fe timer_create: use SIG_SETMASK restore the signal mask.
Bug: http://b/73144101
Test: ran tests
Change-Id: I9adf3a512c120ef2280ad469ad11366222d61463
2018-03-20 17:58:11 -07:00
Josh Gao 6fcba93b17 Filter out reserved signals in functions that take sigset_t.
Prevent processes from blocking libc-reserved signals by filtering them
out.

Bug: http://b/73144101
Test: 32/64-bit bionic-unit-tests-glibc
Test: 32/64-bit bionic-unit-tests on taimen
Change-Id: Ibadcaa7f668ed8be885cc61b67fb4b611fce8b17
2018-02-27 14:12:30 -08:00
Elliott Hughes 5905d6f879 Add `sigset64_t` and accompanying functions.
This doesn't address `struct sigaction` and `sigaction`. That will
come later.

Bug: http://b/72493232
Test: ran tests
Change-Id: I4134346757ce3a4dac6feae413361cec16223386
2018-01-30 18:47:16 -08:00
Elliott Hughes 4b1c6e7385 Better handling of sigset_t on LP32.
The main motivation here is that the sigprocmask in pthread_exit wasn't
actually blocking the real-time signals, and debuggerd (amongst other
things) is using them. I wasn't able to write a test that actually won
that race but I did write an equivalent one for posix_spawn.

This also fixes all the uses of sigset_t where the sigset_t isn't
exposed to the outside (which we can't easily fix because it would be
an ABI change).

Bug: https://issuetracker.google.com/72291624
Test: ran tests
Change-Id: Ib6eebebc5a7b0150079f1cb79593247917dcf750
2018-01-26 13:04:57 -08:00
Elliott Hughes 8963dd337e Make all rt_sigtimedwait signatures match.
There's no change to the generated stubs, because the script only cares
that this is a pointer type, not what it's a pointer to.

Change-Id: I766720965f0f3d201fc90677a076b26870485377
2016-05-23 11:20:19 -07:00
Elliott Hughes d1aea30b2a Fix POSIX timer thread naming.
Spencer Low points out that we never actually set a name because the constant
part of the string was longer than the kernel's maximum, and the kernel
rejects long names rather than truncate.

Shorten the fixed part of the string while still keeping it meaningful. 9999
POSIX timers should be enough for any process...

Bug: https://code.google.com/p/android/issues/detail?id=170089
Change-Id: Ic05f07584c1eac160743519091a540ebbf8d7eb1
2015-04-25 10:05:24 -07:00
Yabin Cui 95f1ee235a Change on handling of SIGEV_THREAD timers.
1. Don't prevent calling callback when SIGEV_THREAD timers are disarmed by timer_settime.
As in POSIX standard: The effect of disarming or resetting a timer with pending
expiration notifications is unspecified. And glibc didn't prevent in this situation, so I
think it is fine to remove the support.
2. Still prevent calling callback when SIGEV_THREAD timers are deleted by timer_delete.
As in POSIX standard: The disposition of pending signals for the deleted timer is unspecified.
However, glibc handles this (although that is not perfect). And some of our tests in
time_test.cpp depend on this feature as described in b/18039727. so I retain the support.
3. Fix some flaky test in time_test.cpp, and make "time*" test pass on bionic-unit-tests-glibcxx.

Bug: 18263854

Change-Id: I8ced184eacdbfcf433fd81b0c69c38824beb8ebc
2015-04-15 17:36:01 -07:00
Elliott Hughes 05fc1d7050 Add missing includes.
Change-Id: Ibf549266a19a67eb9158d341a69dddfb654be669
2015-01-28 19:23:11 -08:00
Christopher Ferris 62d84b1935 Fix race condition in timer disarm/delete.
When setting a repeat timer using the SIGEV_THREAD mechanism, it's possible
that the callback can be called after the timer is disarmed or deleted.
This happens because the kernel can generate signals that the timer thread
will continue to handle even after the timer is supposed to be off.

Add two new tests to verify that disarming/deleting doesn't continue to
call the callback.

Modify the repeat test to finish more quickly than before.

Refactor the Counter implementation a bit.

Bug: 18039727

(cherry pick from commit 0724132c32)

Change-Id: I135726ea4038a47920a6c511708813b1a9996c42
2014-10-22 13:20:39 -07:00
Elliott Hughes a4831cb4a3 Add pthread_gettid_np and re-expose __get_thread for LP32.
A lot of third-party code calls the private __get_thread symbol,
often as part of a backport of bionic's pthread_rwlock implementation.
Hopefully this will go away for LP64 (since you're guaranteed the
real implementation there), but there are still APIs that take a tid
and no way to convert between a pthread_t and a tid. pthread_gettid_np
is a public API for that. To aid the transition, make __get_thread
available again for LP32.

(cherry-pick of 27efc48814b8153c55cbcd0af5d9add824816e69.)

Bug: 14079438
Change-Id: I43fabc7f1918250d31d4665ffa4ca352d0dbeac1
2014-09-11 16:22:50 -07:00
Elliott Hughes 0990d4fda8 Make SIGRTMIN hide the real-time signals we use internally.
__SIGRTMIN will continue to tell the truth. This matches glibc's
behavior (as evidenced by the fact that we don't need a special case
in the strsignal test now).

Change-Id: I1abe1681d516577afa8cd39c837ef12467f68dd2
2014-04-30 10:06:09 -07:00
Elliott Hughes 473d06707b Fix the POSIX timers fix.
If we're not going to wait for the timer threads to exit, we need
another way to ensure that we don't free the data they're using
prematurely. The easiest way to ensure that is to let them free the
data themselves.

Change-Id: Icee17c87bbcb9c3aac5868973f595d08569f33aa
2014-04-01 19:07:52 -07:00
Christopher Ferris 753ad778bc Fix deadlock in timer_delete.
If the callback function for a timer did a timer_delete, the function
would never return. The problem was that the timer_delete function would try
to wait until the timer thread has finished. Waiting for yourself to finish
doesn't work very well.

Bug: 13397340
Change-Id: Ica123a5bafbc8660c8a4a909e5c2dead55ca429d
2014-03-20 20:47:45 -07:00
Elliott Hughes 4b558f50a4 Rewrite the POSIX timer functions.
This is a much simpler implementation that lets the kernel
do as much as possible.

Co-authored-by: Jörgen Strand <jorgen.strand@sonymobile.com>
Co-authored-by: Snild Dolkow <snild.dolkow@sonymobile.com>
Change-Id: Iad19f155de977667aea09410266d54e63e8a26bf
2014-03-07 16:49:46 -08:00