Well, that has the builtin assumption that the max fileno is 100, which is probably good enough, usually, but it will lead to a really hard to debug problem, eventually. It's actually somewhat of a weakness of perl, I think, that there is no exposed system call to get all open file descriptors. Obvoiously you can deal with this if you compile perl properly, and just refer to the system call by number through syscall()... but still, this is sad.
This is additionally sad because of the behavior of perl's output buffers on fork() (leaving buffers unflushed), since the buffers are duped with the fork, but there is no means by which to systematically flush all buffers before fork(). However, as I understand it, the behavior on fork() is fixed in later versions of perl (I'm still on 5.005_03... but we're working on an upgrade plan to 5.8 soon)... so that's good at least.
------------
:Wq
Not an editor command: Wq
| [reply] [d/l] [select] |
| [reply] |
Yeah, you're right... it's not a system call issue (with the flush on fork), but an issue with the fact that perl doesn't have a fflush() builtin which emulates the fflush() in unix... that is: having the ability to flush all fd's (not just individual named fd's).
Anyway, because I remembered that issue wrong, I made the incorrect leap that there must be an unimplemented-in-perl system call to get all open fd's.
Anyway, my bad. Thanks. Still, it seems like there ought to be a faster way to find all open fd's than iterating through all *possible* fileno's looking for ones that are open fd's. Oh, well.
------------
:Wq
Not an editor command: Wq
| [reply] [d/l] [select] |
A very belated thanks to merlyn!
This code has helped my in a fairly large project.
This was my first post and didn't really know how the site worked at the time, so didn't mention how much this helped me out. | [reply] |