1

Let's assume that I have a file descriptor which is shared among several threads. One thread is currently writing to or reading from it, and also let's assume that this operation is "really slow" (for example it's not a regular disk file, maybe it's an UART terminal on embedded device).

int ret = read(sharedFd, buffer, sizeof(buffer));

Now another thread in closing this shared file descriptor:

int ret = close(sharedFd);

To make it more tricky, let's assume that the thread that does reading/writing was suspended just after it translated the sharedFd index into system's file structure, but before it actually starts the operation (it has the handle to the underlying object, but did not start using it yet). I know that this is a very bad practice, generally not a good code and so on, and so on. But I'm more interested in answer to the following question:

Does any standard (POSIX, C, ...) - directly or indirectly - say that such use case is "undefined behavior"?

The reason for my question is not because I want to write code like that and want to know whether it's good or how to fix it (I know it's generally bad and should be improved by using synchronization like a mutex or semaphore). I'm asking because I'm writing a RTOS for microcontrollers and currently I'm implementing the I/O layer, and at this moment I'm wondering whether my system can safely ignore such issues (therefore blaming every possible outcome of the "undefined behavior" - including instant crash of the whole device - on the user's code) or maybe I should internally handle that somehow (for example by reference counting and actually closing the file only after the last call that uses it returns)?

Freddie Chopin
  • 8,440
  • 2
  • 28
  • 58
  • 1
    Does this answer your question? [C: blocking read should return, if filedescriptor is deleted](https://stackoverflow.com/questions/40301754/c-blocking-read-should-return-if-filedescriptor-is-deleted) – Joseph Sible-Reinstate Monica Jun 03 '20 at 20:31
  • 1
    Or this? [Unix: What happens when a read file descriptor closes while calling select()](https://stackoverflow.com/q/10046200/7509065) Or this? [What does select(2) do if you close(2) a file descriptor in a separate thread?](https://stackoverflow.com/q/543541/7509065) – Joseph Sible-Reinstate Monica Jun 03 '20 at 20:32
  • 1
    By the way, if you're not trying to build a DeathStation 9000, even if you could let everything crash and burn, you shouldn't. I'd suggest you make your OS do one of two things: 1. Have the `read` syscall return with an error 2. Defer actually closing the FD until the `read` is done – Joseph Sible-Reinstate Monica Jun 03 '20 at 20:35
  • @JosephSible-ReinstateMonica - thanks for the links, I've seen them already and they are all about select(). This is similar, but slightly different - these threads tell what happens and I'm more interested in whether any standard says what should happen. The idea to actually handle that rare situation is appealing and generally good, but everything has a cost - such implementation would use more RAM memory and also there would be much more code to write and maintain. – Freddie Chopin Jun 05 '20 at 13:25

0 Answers0