summaryrefslogtreecommitdiff
path: root/locks
Commit message (Expand)AuthorAgeFilesLines
* Axed C++ comments and tabs.fuankg2011-02-181-1/+1
* apr_proc_mutex_child_init calls unimplemented OpenMutexW and will fail towrowe2007-06-011-0/+9
* Update license header.jorton2006-09-2021-126/+126
* Close a kernel layer segfault when the user attempts to lockwrowe2006-03-181-1/+2
* Merge r380120, r382030 from trunk:jorton2006-03-161-3/+3
* Merge r371172 to 0.9.x.rooneg2006-01-261-8/+10
* Win32: fix apr_proc_mutex_trylock() to handle WAIT_TIMEOUT,wrowe2005-09-211-0/+3
* Refactor Win32 condition variables code to address bugs.wrowe2005-07-221-64/+19
* Update copyright year to 2005 and standardize on current copyright owner line.jerenkrantz2005-02-0421-21/+42
* Fixing various compiler errors when compiling against the latest version of L...bnicholes2004-11-291-1/+1
* Merge r65157, r65158 from trunk: (fixing random lockups in pool-debugjorton2004-11-211-109/+36
* Remove .cvsignore files.APR_0_9_BRANCHjorton2004-11-203-12/+0
* thread id is not always a scalargregames2004-07-201-1/+3
* Backport this change as without it we can't build httpd-2.0.49!dreid2004-03-091-0/+5
* Relicense APR under Apache License, Version 2.0.jerenkrantz2004-02-1321-1029/+210
* Backport from HEAD:jorton2004-01-271-4/+4
* Thanks to Jeff for pointing out I didn't point to the atomics.wrowe2003-08-081-3/+3
* Revamp apr_thread_mutex to be as thread safe, and occasionallywrowe2003-08-071-23/+57
* Introduce the proc_mutex_no_tryacquire stub, returning APR_ENOTIMPL,wrowe2003-08-061-5/+9
* Invert the order of marking the lock as released. Since we firstwrowe2003-08-061-5/+5
* Clean up a style issue; apr_get_os_error() is much cleaner.wrowe2003-06-181-13/+13
* Win32: Adopt Brian Havard's OS/2 rwlock implementation.stoddard2003-06-181-41/+107
* Error handling fix (unrelated to previous changes): don't calljorton2003-06-081-1/+0
* Code style cleanups: remove unnecessary casts to and from void *;jorton2003-06-081-8/+3
* POSIX says that passing a mutexattr object with default attributes tojorton2003-06-081-18/+1
* Add proc_mutex_lockfile() for retrieving the name of the filetrawick2003-06-075-0/+32
* Don't require the lock file name to be passed intotrawick2003-06-071-0/+3
* When using a temporary file for flock- and fcntl-based mutexes,trawick2003-06-071-7/+4
* Don't segfault trying to close a file in error paths of flocktrawick2003-04-191-3/+6
* We need to call apr_proc_mutex_child_init, whichjim2003-03-301-1/+4
* Bugz 17186jim2003-03-271-0/+1
* Win32 needs to do nothing if the file handle is already open in a childwrowe2003-03-271-18/+51
* Fix two problems in apr_thread_cond_timedwait, the first observed bywrowe2003-02-271-2/+3
* When we generate our own semaphore name (internally) when usingjim2003-02-231-7/+23
* rename apr_arch_fileio.h to apr_arch_file_io.h for consistencythommay2003-01-075-5/+5
* Namespace protection for include/arch/ header filesthommay2003-01-0621-34/+34
* Update copyright notices to 2003.thommay2003-01-0121-21/+21
* A second stab at getting apr_thread_cond_timedwait to work. Someonewrowe2002-12-311-2/+2
* Fix up code in thread_cond. First always escape the case where we outrightwrowe2002-12-291-23/+72
* OS/2: Make apr_proc_mutex_cleanup() public to match recent API change.bjh2002-11-231-3/+3
* Implemention of apr_proc_mutex_cleanup() for NetWarebnicholes2002-11-221-0/+5
* axe the remaining proc_mutex_FOO_destroy() functions, which aretrawick2002-11-211-44/+1
* get apr_proc_mutex_destroy() out from undertrawick2002-11-211-6/+6
* apr_proc_mutex_destroy should be exported.rbb2002-11-211-1/+1
* Register the proc_mutex cleanup with an exported API. Most of thisrbb2002-11-201-23/+18
* Rip out buggy nested-mutex code from apr_proc_mutex. This should fix subtleaaron2002-11-181-58/+3
* Whoa Nelly! Lots of errors in the global mutex failure cases. We havewrowe2002-10-291-17/+32
* Handle leaks right now are a huge problem. Close two of them.wrowe2002-07-311-6/+2
* Collapse this down to the infinately more readable apr_pool_cleanup_run().aaron2002-07-301-6/+1
* When we are destroying a mutex we don't know if it is locked or not,aaron2002-07-301-1/+0