Hi,
I want to kill a thread in my Genode program and on non-Linux base I currently do this:
```c++ main_obj->_env.cpu().kill_thread(Thread::myself()->cap()); ```
However, this does not work when I use Linux as a base. From what I understand this is due to capabilities being emulated on Linux.
Is there a function similar to the one above that will work for Linux?
Best, Rumen
Hello Rumen,
as you discovered, the thread capability is merely a low-level mechanism. It should normally not be used directly.
Is there a function similar to the one above that will work for Linux?
To kill a thread, destruct the 'Thread` object. Without precautions, however, this brutal method may still have unwelcome side effects as the killed thread may be in an intermediate state like holding a lock. A thread killing itself is a no-go because its execution might crease mid-way during its destruction, provoking inconsistencies like a missing release of the thread's stack.
It is best to have a clear notion of ownership. The one thread who creates another thread should be the one destroying it.
For the destruction, it is advisable to implement a clean wind-down procedure (e.g., the to-be-killed thread signals its owner that it is ready to be destructed) and let the owner call 'Thread::join' before destructing the 'Thread' object.
Cheers Norman
Hello Norman,
What if I should kill the thread which hangs in some unknown state? Eg it try to read smart card which was forcibly removed? Any mechanism to isolate consequences? This is a real life example for kind of embedded devices…
Alexander
19 сент. 2025 г., в 13:41, Norman Feske norman.feske@genode-labs.com написал(а):
Hello Rumen,
as you discovered, the thread capability is merely a low-level mechanism. It should normally not be used directly.
Is there a function similar to the one above that will work for Linux?
To kill a thread, destruct the 'Thread` object. Without precautions, however, this brutal method may still have unwelcome side effects as the killed thread may be in an intermediate state like holding a lock. A thread killing itself is a no-go because its execution might crease mid-way during its destruction, provoking inconsistencies like a missing release of the thread's stack.
It is best to have a clear notion of ownership. The one thread who creates another thread should be the one destroying it.
For the destruction, it is advisable to implement a clean wind-down procedure (e.g., the to-be-killed thread signals its owner that it is ready to be destructed) and let the owner call 'Thread::join' before destructing the 'Thread' object.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
users mailing list -- users@lists.genode.org To unsubscribe send an email to users-leave@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/mes...
Hello Alexander,
On 2025-09-19 22:18, Alexander Tormasov via users wrote:
What if I should kill the thread which hangs in some unknown state? Eg it try to read smart card which was forcibly removed? Any mechanism to isolate consequences? This is a real life example for kind of embedded devices…
Threads are rarely an adequate mechanism for isolating trouble. They are more commonly a mechanism for introducing trouble. Unless in need to distribute computational work across multiple CPU cores, I would shy away from using threads.
Your smart-card interaction problem may best be solved by implementing the component as a state machine by explicitly modelling the flakiness of the smartcard and *never* block for I/O in the first place. A good example is the modem driver, which stays responsive regardless of all the silly things the modem is doing.
[1] https://github.com/genodelabs/genode-allwinner/tree/master/src/driver/modem/...
Alternatively, you can wrap the fragile smart-card interaction in a separate component, monitor its health from the outside, and re-spawn it when needed. So you plan ahead for its anticipated failure. This is the approach taken by the depot-download [2] tool to protect itself from all kinds of trouble (network connectivity, archive extraction, etc.).
[2] https://github.com/genodelabs/genode/tree/master/repos/gems/src/app/depot_do...
Cheers Norman
-
Alexander Tormasov -
Norman Feske -
Rumen Mitov