| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This finally removes the use of the Mutex and Condition classes. This is an
intricate patch as the Mutex and Condition classes were tied together.
Furthermore, many places had slightly differing uses of time values. Convert
timeout values to relative everywhere to permit the use of
std::chrono::duration, which is required for the use of
std::condition_variable's timeout. Adjust all Condition and related Mutex
classes over to std::{,recursive_}mutex and std::condition_variable.
This change primarily comes at the cost of breaking the TracingMutex which was
based around the Mutex class. It would be possible to write a wrapper to
provide similar functionality, but that is beyond the scope of this change.
llvm-svn: 277011
|
|
|
|
|
|
| |
multi-threaded test case. The error would cause an assertion that could cause lldb to crash when unlocking a mutex returned an error because it was in use.
llvm-svn: 243067
|
|
|
|
|
|
|
|
| |
Fix the warning the correct way without making things crash when ENABLE_MUTEX_ERROR_CHECKING is non enabled.
<rdar://problem/17703039>
llvm-svn: 213394
|
|
|
|
|
|
|
| |
- factorize unistd.h and stdbool.h in lldb-types.h.
- Add <functional> and <string> where required.
llvm-svn: 189477
|
|
|
|
|
|
| |
portability.
llvm-svn: 189107
|
|
|
|
| |
llvm-svn: 183140
|
|
|
|
| |
llvm-svn: 179892
|
|
|
|
|
|
|
|
|
|
|
| |
Implement the ability for Python commands to be interrupted by pressing CTRL+C
Also add a new Mutex subclass that attempts to be helpful for debugging by logging actions performed on it
FYI of all interested - there is a separate deadlocking issue related to how LLDB dispatches CTRL+C that might cause LLDB to deadlock upon pressing CTRL+C while in a Python command.
This is not a regression, and was just previously masked by us not even trying to bail out of Python commands, so that it would not be clear from a user perspective whether we were
deadlocked or stuck in an inconsistent state within the Python interpreter.
llvm-svn: 170612
|
|
|
|
|
|
|
|
| |
- as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations
Patch by Matt Kopec!
llvm-svn: 169633
|
|
|
|
|
|
|
|
| |
- use macros from inttypes.h for format strings instead of OS-specific types
Patch from Matt Kopec!
llvm-svn: 168945
|
|
|
|
| |
llvm-svn: 159929
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it, rather
than being given the pthread_mutex_t from the Mutex and locks that. That allows us to
track ownership of the Mutex better.
Used this to switch the LLDB_CONFIGURATION_DEBUG enabled assert when we can't get the
gdb-remote sequence mutex to assert when the thread that had the mutex releases it. This
is generally more useful information than saying just who failed to get it (since the
code that had it locked often had released it by the time the assert fired.)
llvm-svn: 158240
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make
that work, we should maintain the Mutex abstraction and not pass around the
platform implementation...
Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor
taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass
your mutex to a Locker (you can't in fact, since I made it private.)
llvm-svn: 156221
|
|
|
|
|
|
|
|
|
| |
the mutex handed in, not the m_mutex_ptr that you've set to NULL...
Rework the Host.cpp::ThreadNameAccessor to use ThreadSafeSTLMap - we've got it so we might as well use it. Also works around a problem with the
Mutex::Locker class raising fallacious asserts in debug mode when used with pthread_mutex_t's that weren't backed by Mutex objects.
llvm-svn: 156193
|
|
|
|
|
|
|
|
| |
checking for LLDB mutex validity are static so
that entries put in there actually persist between
calls to error_check_mutex.
llvm-svn: 154727
|
|
|
|
|
|
| |
initialized.
llvm-svn: 154710
|
|
|
|
|
|
| |
we always check if a mutex is valid prior to doing stuff with it. We also track when mutexes are initialized and destroyed and keep these in sets that can very subsequent pthread_mutex_XXX API calls.
llvm-svn: 154637
|
|
|
|
|
|
|
|
| |
Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.
Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance.
llvm-svn: 154458
|
|
|
|
| |
llvm-svn: 149140
|
|
|
|
|
|
|
|
|
|
| |
watching for errors from pthread_mutex_destroy () (usually "Resource
busy" errors for when you have a mutex locked and try to destroy
it), and pthread_mutex_lock, and pthread_mutex_unlock (usually for
trying to lock an invalid mutex that might have possible already
been freed).
llvm-svn: 149135
|
|
|
|
|
|
| |
Thanks Bruce!
llvm-svn: 123083
|
|
code between linux, darwin and BSD.
llvm-svn: 113263
|