in reply to Why do we need to close filehandles?

In addition to what others said:

Filehandles are a limited resource. Typically, a process is limited to 20 to about 200 file handles, trying to open more handles will result in errors. The reason for this limit is that file handles have a price. The OS needs to allocate some memory for the file meta-data (where on the disk is the file, at what offset will data be read/written, and so on) and some more memory for the file contents. Unwritten data has to be buffered in memory, because disk writes and even flash writes are waaaaay slower than writing to RAM. So every common OS attempts to write only when really needed, preferably without blocking the entire system.

Aborting a program which still has file handles opened is unpredictable, because the libc can also buffer data, in addition to the operating system. Wheather or not the data buffered in the libc ends in the file depends on how the libc is implemented and how the program is aborted. Therefore, the general advice is to keep files opened as short as possible, so that libc and OS can flush their buffers to the disk.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
  • Comment on Re: Why do we need to close filehandles?

Replies are listed 'Best First'.
Re^2: Why do we need to close filehandles?
by locked_user sundialsvc4 (Abbot) on May 01, 2011 at 15:51 UTC

    As a complete “aside point,” I normally do not ask my applications to “flush buffered data to disc.”   If you want to see just how badly this can affect performance (albeit with a perfectly good reason in this case), try using an SQLite database without using transactions.   Just let the data sit in the operating-system buffers as it normally does, and basically just let the OS do its thing.   But, when you have reached a logical end-point in whatever it is that you are doing, explicitly inform the operating system that you have done so, by closing the file.

    Writes to things like flash-cards can be astonishingly slow, continuing for many seconds after the application has closed.   That is why it is paramount to drill-in to your users that they must dismount the cards, and wait for that process to finish, before removing the cards from the USB port.   (You’ve got maybe a 50% chance that your grandmother will actually listen to you, but maybe that’s better than nothing.)

      Or wait for the light on the device to change state, like an old school floppy drive.

      But that's not 100% guaranteed.

[reply]

In Section Seekers of Perl Wisdom