Re: Cleaning up after timer_delete

["Carlos O'Donell" <carlos at systemhalted dot org>]

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."

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.

>> 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.

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.

Cheers,
Carlos.