The stream isn’t closed; the fact that you are able to try writing to it without receiving an EBADF error is proof of that. (See man 2 write for details.)
On Linux, given that you’re looking at a pipe, what you could do is check all running processes to see if any other has an open file descriptor to the same pipe. If you find one, then the pipe is still usable for writing without error; if you don’t then either you don’t have appropriate privileges to see the reading process, or the pipe is no longer usable for writing.
lsof can be used for that. Example:
$ sleep 3m | sleep 10 &
[1] 62807 62808
$ lsof -p 62807 -ad 1 +E
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sleep 62807 stephane 1w FIFO 0,14 0t0 806533 pipe 62808,sleep,0r
sleep 62808 stephane 0r FIFO 0,14 0t0 806533 pipe 62807,sleep,1w
Stdout of 62807 (running sleep 3m) is open on the writing end of a pipe, and there's still a process (running sleep 10) with a fd (here 0) open on the reading end.
Same command run after 10 seconds:
$ lsof -p 62807 -ad 1 +E
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sleep 62807 stephane 1w FIFO 0,14 0t0 806533 pipe
This time, lsof can't find any other fd open for reading on the pipe upon on fd 1 of 62807.
Without lsof, you can do the equivalent of this zsh code:
$ sleep 3m | sleep 4m &
[1] 63098 63100
$ ls -ogd /proc/*/fd/*(e['[[ $REPLY -ef /proc/63098/fd/1 ]]'])
l-wx------ 1 64 Oct 20 17:12 /proc/63098/fd/1 -> 'pipe:[810032]'
lr-x------ 1 64 Oct 20 17:12 /proc/63100/fd/0 -> 'pipe:[810032]'
Permissions of those symlinks indicate how the pipe is open for each process.
See also How to find out if pipe is broken?
