-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pthread cancel #5
Comments
Hello @nslowell, Not all interfaces specified by POSIX Threading standard are implemented, since this project is a "lab project" nor we could claim we are "POSIX compliant". Though, if features are needed, we are happy to investigate what it takes to implement. In this case |
The reason it is not implemented is that cancellation points are exceedingly difficult to decypher. See https://lwn.net/Articles/683118/ for some more information. The TLDR; for that is that threads may only be cancelled when a specific set of conditions are met according to the Posix standard, this is called a cancellation point, one example is that a thread may not be cancelled while it is holding on to a mutex or semaphore, but it gets quite a bit more complex than this. If you look at this man page you will see the list of functions we will have to change to manage the cancellation points. Once we have completed this list we will be able to do pthread_cancel. It is a LOT of work. Here is the list from the man-page: Cancellation points
|
Since I'm on this thread, here's my opinion.
The design was shared in email some time ago, posting that would be a good starting point to get community contribution. And of course it is up to the FreeRTOS team to define the scope for FreeRTOS-POSIX, as POSIX alone is huge. I'm dropping from this conversation now. |
@yuhui-zheng , I am not sure I understand what you mean with regard to "read/readv" applicability to FreeRTOS above? As you know a "stream" in C is called a "FILE" (for historical reasons) and functions like scanf and printf will typically make use of these IO streams, which seems very relevant to FreeRTOS. We use it with serial ports on devices all of the time? I am also not sure what you mean by "In this case, what it really takes to support thread cancellation is to update pthread data structure to track thread cancellation state.", but your comments for sure has me hopeful. If you have a suggestion how we could implement this relatively simply (which it sure sounds like you have) then I would love to give it a try! From what I can gather a call to pthread_cancel must cause a target thread to - at a later point in time, and in the context of the target thread (not the caller) kill itself, including running any pushed cleanup handlers. If the target thread is suspended at the time of the request, due to something like e.g. pthread_cond_wait, the target thread shoud be awakened and it should then cancel itself when next scheduled. One curiosity here is that pthread_mutex_lock() is NOT a cancellation point, which means that if the target thread is blocked waiting on a mutex you will need a mechanism to unblock it conditionally depending on whether the mutex it is blocked by is a cancellation point mutex or a non-cancellation point mutex. I am not saying that this is not possible, of course it is possible, but this seems rather hard to implement without doing a lot more than simply tracking cancellation state? |
Where is pthread_cancel? Why is it not implemented?
The text was updated successfully, but these errors were encountered: