Re: Cleaning up after timer_delete

["Rémi Denis-Courmont" <remi at remlab dot net>]

Le dimanche 26 juillet 2009 18:48:12 Carlos O'Donell, vous avez écrit :
> 2009/7/26 Rémi Denis-Courmont <remi@remlab.net>:
> > The only piece of data that the lock has is the pointer. That pointer, as
> > far as I know, cannot be changed through the life time of the timer,
> > which excludes changing it to some "error" value.
>
> Well, it can, the pointer points to a struct that likely has *some*
> alignment value e.g. low 2 or 3 bits are zero, you could set the low
> bit to indicate "deleted."

I thought about that, i.e. using posix_memalign(). However the pointer is set 
in stone when creating the timer. So there is no way (that I know) to flip the 
low-order bit.

> However, this doesn't help. IIUC the sigval is a copy of the sigval
> you passed the kernel. If it is a copy, then changing the original
> ev.sigev_value won't change what the thread sees.

Yes.

> >> Protect the resource with a lock?
> >
> > To protect the resource with a lock, I need to create a new resource that
> > contains a lock and a pointer to the original resource:
> >
> > struct safe_resource
> > {
> >        pthread_mutex_t lock;
> >        struct foo *resource;
> >        //bool deleted;
> > };
> >
> > Now when can I delete the new lock and the safe_resource structure? They
> > have to be allocated somewhere... Adding a lock just moves the problem.
>
> Yes, you can't delete the safe_resource struct, but you can delete the
> resource.
>
> The lock is a fixed 4 bytes (on most targets), but the resource could
> be potentially a very large structure.

A POSIX mutex is 24 bytes on glibc.

> This is certainly a step forward, you will leak 8 bytes for each
> safe_resource you allocate, instead of the entire resource structure.
>
> I agree that it's not a very nice situation. The alternative is to
> recycle the safe_resource structure, and use a typefield to prevent an
> old thread from using the recycled value e.g. old thread function runs
> only type "A" resources, newly allocated resource is type "B", so old
> thread avoids running it, and exits.
>
> This is certainly a tough question, it's a shame POSIX doesn't give a
> recommendation.

I think it's just impossible to cleanly use interval timers in a library. It 
works OK in the "main" program where you can use signals, static data, etc, 
but not in generic shared object libraries :(

-- 
Rémi Denis-Courmont
http://www.remlab.net/