axos88 wrote on Friday, March 16, 2012:
Okay, I understand, however the API documentation lacks this note. Actually I find the API documentation pretty lacking in itself, but that is another issue.
Do you think this could be worked around somehow?
For the scenario:
I am writing a connection-based network stack.
Suppose one task opens a connection to a remote machine, and tries to read data from the socket, however it blocks, as there is no data pending. I am using semaphores here for waiting.
Now suppose something goes wrong, and the remote closes the connection, or the connection times, out or whatever.
The socket should now go into the closing state, sending the close connection messgaes, and eventually cleaning up all semaphores, and resources used, even the one that the task is still waiting for for the read.
And there might be multiple tasks waiting for the socket, so “just setting” the semaphore, and indicating via some variable that the connection is closing is not really an option either, because i have no idea how many time it needs to be set, and also just by setting the semaphore does not guarantee that the waiting task gets scheduled, and gets out of the kernel function.
Do you have any idea what I could do in such a situation?