0

I'm experimenting with a fictional server/client application where the client side launches request threads by a (possibly very large) period of time, with small in-between delays. Each request thread writes on the 'public' fifo (known by all client and server threads) the contents of the request, and receives the server answer in a 'private' fifo that is created by the server with a name that is implicitly known (in my case, it's 'tmp/processId.threadId').

The public fifo is opened once in the main (request thread spawner) thread so that all request threads may write to it. Since I don't care about the return value of my request threads and I can't make sure how many request threads I create (so that I store their ids and join them later), I opted to create the threads in a detached state, exit the main thread when the specified timeout expires and let the already spawned threads live on their own.

All of this is fine, however, I'm not closing the public fifo anywhere after all spawned request threads finish: after all, I did exit the main thread without waiting. Is this a small kind of disaster, in which case I absolutely need to count the active threads (perhaps with a condition variable) and close the fifo when it's 0? Should I just accept that the file is not explicitly getting closed, and let the OS do it?

BMendes
  • 37
  • 5
  • Why don't you use [`fuser`](https://linux.die.net/man/1/fuser) to check if some process still uses the fifo? – Zoso Apr 26 '21 at 18:42
  • Since there is no `C` or OS specificity beyond what you are asking for in a design, you might consider replacing the language and OS tags with `algorithm`. – ryyker Apr 26 '21 at 19:34
  • Also, [your detached threads will exit on the main thread exiting](https://stackoverflow.com/a/4667273/1851678). – Zoso Apr 26 '21 at 19:40
  • I'm exiting the main thread using `pthread_exit(NULL)` and the detached threads are indeed outliving the main thread. Isn't this the supposed behaviour? – BMendes Apr 26 '21 at 19:45
  • I need my application to handle this in an automated way. Do you mean polling the `fuser` utility via the `system` kernel call? – BMendes Apr 26 '21 at 19:47
  • 1
    Yes, @BMendes, it is expected that terminating the main thread via `pthread_exit()` will allow the process to continue until all other threads belonging to it have also terminated. It will not forcibly terminate other threads. – John Bollinger Apr 28 '21 at 16:40

2 Answers2

0

I managed to solve this issue setting up a cleanup rotine with atexit, which is called when the process terminates, ie. all threads finish their work.

BMendes
  • 37
  • 5
0

All of this is fine, however, I'm not closing the public fifo anywhere after all spawned request threads finish: after all, I did exit the main thread without waiting. Is this a small kind of disaster, in which case I absolutely need to count the active threads (perhaps with a condition variable) and close the fifo when it's 0? Should I just accept that the file is not explicitly getting closed, and let the OS do it?

Supposing that you genuinely mean a FIFO, such as might be created via mkfifo(), no, it's not a particular issue that the process does not explicitly close it. If any open handles on it remain when the process terminates, they will be closed. Depending on the nature of the termination, it might be that pending data are not flushed, but that is of no consequence if the FIFO is used only for communication among the threads of one process.

But it possibly is an issue that the process does not remove the FIFO. A FIFO has filesystem persistence. Once you create one, it lives until it no longer has any links to the filesystem and is no longer open in any process (like any other file). Merely closing it does not cause it to be removed. Aside from leaving clutter on your filesystem, this might cause issues for concurrent or future runs of the program.

If indeed you are using your FIFOs only for communication among the threads of a single process, then you would probably be better served by pipes.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • The client and the server are two separate processes. The server is responsible for this named pipe creation, opening and closing, but does not remove it from the filesystem once its finished. Leaving the clutter argument aside, will I have data integrity issues if I fire up the client and the server again, with the same fifo that was previously used and not closed by the client? – BMendes Apr 28 '21 at 18:10
  • @BMendes, FIFOs have no enduring contents. They will not retain data when neither end is open, so you don't have to worry about stale data being held over. But you might well face issues if a second server process were ever launched while any of the clients of a previous server were still running, and especially if two servers were running at the same time, trying to use the same FIFO. – John Bollinger Apr 28 '21 at 18:17
  • Would these problems be caused by not having closed the fifo in the client side? – BMendes Apr 28 '21 at 19:08