[riot-notifications] [RIOT-OS/RIOT] What's the most RIOT-like way for a shell command to quit on ^C without wasting a thread to block on reading stdin? (#10715)
Juan I Carrano
notifications at github.com
Mon Mar 4 15:19:58 CET 2019
First let me begin by noting that your question is very valid. The behaviour you described, however it is implemented, should be possible to achieve _without an additional thread_. The fact that it is not (at least not easily) means that there is something wrong that we need to fix.
To answer to your comment in #11004 .
> I didn't test this yet but it sounds like you're thinking this should terminate a running process with ^C (that's what #10715 is about) which would be lovely too
There's no "easy" way of doing that. Aside from RIOT specifics, which may make the task harder (or easier) the main obstacle with that is that there are no "processes" in RIOT, only threads. AFAIK this is also true of the other major embedded OSes that target this class of devices. Now, which thread gets killed on CTRL-C? Clearly not the "running" thread (any thread could be running at that instant). In a UNIX terminal, the foreground process is terminated (not really, see next point) but there is no "foreground thread" in RIOT. Finally, tasks should not be _killed_ by ctrl-c, there has to be some graceful termination/cleanup, etc.
The last point is where we have more trouble now, as you well mention in your post. The function/thread that implements the command must wait for at least two different types of events: the one it needs in order to achieve its purpose and the "termination" event. It could also be implemented in the IO layer component that implements the message buffer pseudo-file (an interrupted read could return EINTR).
How are you implementing the message pseudo-file? If it is done with a message queue, it is a matter of sending another message on ctrl-c to the same queue. If it is implemented with a raw circular buffer protected by locks, then the locks could be made [interruptible](https://www.kernel.org/doc/htmldocs/kernel-locking/API-mutex-lock-interruptible.html).
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications