A PipedInputStream
/ PipedOutputStream
do not hold any operating system resources. So any advice that says that daemon threads should not hold resources does not apply here. (But see below!)
However, this doesn't mean that you don't ever need to close()
(at least) the PipedOutputStream
. Depending on your application, the corresponding PipedInputStream
may need the pipeline to be closed to complete its work.
Regarding the other answer:
After looking at the Answer and the comments, I think that his argument is an over-generalization:
He is correct that anything (daemon thread or whatever) that has lots (he says "hundreds") of resources open at the same time is a bad idea.
He is also correct in saying that doing critical file updates in a daemon thread is risky. But doing critical file updates in any thread in Java has the same risk1. Or in C. You just need to design the update sequence to be fail-safe ... or rely on something like DB transactions for fail-safety.
However, it is not logically sound (or pragmatically sensible) to generalise this to saying that daemon threads shouldn't hold resources. Clearly there are use-cases where the above concerns do not apply.
1 - The application may get a "kill -9" which will cause it to exit immediately without running the shutdown hooks. The application may get a "file system full" in the middle of the critical update. The power may go off. And so on ...