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 thi
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 "LOCK_FLAGS_
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
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
>>
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 fr
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 lock_file_list),
that means we have to be careful
6 matches
Mail list logo
