Am 4/7/2014 1:34, schrieb Michael Haggerty:
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from
On 04/07/2014 08:16 AM, Johannes Sixt wrote:
Am 4/7/2014 1:34, schrieb Michael Haggerty:
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects
Am 4/7/2014 13:13, schrieb Michael Haggerty:
On 04/07/2014 08:16 AM, Johannes Sixt wrote:
Am 4/7/2014 1:34, schrieb Michael Haggerty:
So, instead of encoding part of the lock_file state in the filename
field, add a new bit LOCK_FLAGS_LOCKFILE_ACTIVE to flags, and use
this bit to distinguish
On 04/07/2014 02:12 PM, Johannes Sixt wrote:
Am 4/7/2014 13:13, schrieb Michael Haggerty:
On 04/07/2014 08:16 AM, Johannes Sixt wrote:
Am 4/7/2014 1:34, schrieb Michael Haggerty:
So, instead of encoding part of the lock_file state in the filename
field, add a new bit
On Mon, Apr 07, 2014 at 03:12:49PM +0200, Michael Haggerty wrote:
How far *do* you want to go? I'm certainly not opposed to field-test your
current changeset (plus and adjustment to use sig_atomic_t) -- overall it
is an improvement. And then we will see how it works.
For now I think I'd
5 matches
Mail list logo
