evl_demote_thread() leaves dev file of the tread

evl_demote_thread() leaves dev file of the tread

[Steub, Peter]

In my application I have a fallback solution to kill a oob thread, if the regular way of closing the thread fails and a timeout runs out. 
I do this by calling evl_demote_thread() and pthread_cancel() afterwards. This seems to work, evl_demote_thread() gives me a 0 returnvalue, and the thread is gone after pthread_cancel(). 

When I create a new thread, and try to put it in oob mode with the same name using evl_attach_self(), I get EEXIST (-17) from evl_attach_self().
Am I doing it wrong? Is there another way to do a detach from outside the thread? Do I need to do something more then evl_demote_thread() to really get rid of the thread?

I am on evl 0.52 right now.

Thank you.

Mit freundlichen Grüßen / kind regards

i. A. Peter Steub

Re: evl_demote_thread() leaves dev file of the tread

[Philippe Gerum]

"Steub, Peter" <Peter.Steub@baumueller.com> writes:

> In my application I have a fallback solution to kill a oob thread, if the regular way of closing the thread fails and a timeout runs out. 
> I do this by calling evl_demote_thread() and pthread_cancel() afterwards. This seems to work, evl_demote_thread() gives me a 0 returnvalue, and the thread is gone after pthread_cancel(). 
>
> When I create a new thread, and try to put it in oob mode with the same name using evl_attach_self(), I get EEXIST (-17) from evl_attach_self().
> Am I doing it wrong? Is there another way to do a detach from outside the thread? Do I need to do something more then evl_demote_thread() to really get rid of the thread?
>
> I am on evl 0.52 right now.

== TL;DR:

Assuming tfd is the file descriptor obtained from the
evl_attach_{thread/self]() call, you should use the following sequence
to respawn the target thread multiple times, possibly within a short
time window:

pthread_cancel(tid);
pthread_join(tid, NULL);
close(tfd);


== Long story:

The lifetime of all so-called EVL "elements" (e.g. threads, monitors,
proxies, observables etc) is managed by the regular VFS. Each of them is
represented by a virtual device in the kernel, therefore we can get any
number of regular file descriptors referring to such device. As long as
a valid file descriptor refers to the device, the associated element
cannot go stale.

For this reason, closing all file descriptors referring to an element is
required to release the device along with other resources attached to
the element in the core, allowing for the final disposal to take
place. Failing to do so prevents the creation of another instance with
the same name in the same class of elements.

This is now illustrated by the unit test which was added to the -next
branch a short time ago [1].

[1]
https://gitlab.com/Xenomai/xenomai4/libevl/-/commit/a54d987dd3dee297f579078720fd648ce12a77b3

-- 
Philippe.