in reply to Re: FileHandle objects as data members of another object
in thread FileHandle objects as data members of another object

You're consuming a resource (3 open filehandles). This is 'small' (~1024, configurable) and finite on some platforms (most Unices, not Windows).
C:\temp\test>perl -e "{open my $f,'>',++$a or die qq|$a: $!|;push @a,$
+f;redo}
2046: Too many open files at -e line 1.

[download]

Replies are listed 'Best First'.
Re^3: FileHandle objects as data members of another object
by jbert (Priest) on Oct 23, 2006 at 08:16 UTC
    Is that cygwin? I don't think Windows puts a limit on the number of file handles a process can open (other than limits regarding system memory and other mad upper bounds).
[reply]
      Is that cygwin? I don't think Windows puts a limit on the number of file handles a process can open (other than limits regarding system memory and other mad upper bounds).

      No, M$ Windows XP Home Edition Service Pack 2.

[reply]
        Hmm. fopen/open on Windows (the userspace C stdio and unix-like API) have limits like that but the underlying OS facilities don't (unlike Unix - the per-process limit there is a kernel thing).

        I'd naively thought that native (non-cygwin) perl would have gone all the way down to OpenFile() and friends rather than use the unix-like versions.

        You learn something every day.

[reply]
        Windows puts no limit on open files as long as you use the CP/M compatibility functions, which don't work on NT-derived Windows anymore. And on Win95 and later I think they put a strain on some other scarce resource, so effectively you can't use them that way too. So your sentence is right for Win 3.11 and older, and only with (even then) deprecated programming style.
[reply]

In Section Seekers of Perl Wisdom