| d1aea30b2ade504550f7bb7996c808b9af1c415d |
|
25-Apr-2015 |
Elliott Hughes <enh@google.com> |
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
|
| 95f1ee235ae257802a94d7e94d476ea0aaea5cd8 |
|
14-Jan-2015 |
Yabin Cui <yabinc@google.com> |
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
|
| 05fc1d7050d5451aea08dc5f504d2670287b2d43 |
|
29-Jan-2015 |
Elliott Hughes <enh@google.com> |
Add missing includes.
Change-Id: Ibf549266a19a67eb9158d341a69dddfb654be669
|
| 62d84b19359a8ddd3df5b6293d1b05ef5281f532 |
|
21-Oct-2014 |
Christopher Ferris <cferris@google.com> |
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 0724132c3263145f2a667f453a199d313a5b3d9f)
Change-Id: I135726ea4038a47920a6c511708813b1a9996c42
|
| 0724132c3263145f2a667f453a199d313a5b3d9f |
|
21-Oct-2014 |
Christopher Ferris <cferris@google.com> |
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
Change-Id: I73192c915cdacf608521b1792c54e5af14a34907
|
| a4831cb4a3f44b93788488db8ff9ea76613f0355 |
|
12-Sep-2014 |
Elliott Hughes <enh@google.com> |
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
|
| 27efc48814b8153c55cbcd0af5d9add824816e69 |
|
12-Sep-2014 |
Elliott Hughes <enh@google.com> |
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.
Bug: 14079438
Change-Id: I43fabc7f1918250d31d4665ffa4ca352d0dbeac1
|
| 0990d4fda898ada86e557f872f5cb7d16b138e3c |
|
30-Apr-2014 |
Elliott Hughes <enh@google.com> |
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
|
| 473d06707bccf0dd707905dcbe74ba91c4d1e8a5 |
|
02-Apr-2014 |
Elliott Hughes <enh@google.com> |
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
|
| 753ad778bc1c3aecc4cd82b8387a7dc8a9b44d34 |
|
21-Mar-2014 |
Christopher Ferris <cferris@google.com> |
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
|
| 4b558f50a42c97d461f1dede5aaaae490ea99e2e |
|
05-Mar-2014 |
Elliott Hughes <enh@google.com> |
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
|