From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 571CC20798; Fri, 13 Jan 2017 08:02:09 +0000 (UTC) Date: Fri, 13 Jan 2017 08:02:09 +0000 From: Eric Wong To: misc@80x24.org Subject: Perl5 vs *nix filesystem refcounting Message-ID: <20170113080209.GA5402@whir> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline List-Id: Cyclic references is one of the few major problems for reference counting implementations in managing resource reclamation. In Perl 5, cyclic references must be prevented or broken by the programmer if they wish to prevent running out of memory. To the contrary, it's never been a problem for *nix filesystems because of one important design decision: Directories may not have hard links. In other words: Container types may only have a single reference. On the filesystem there is one container type: directories. References on an FS are filenames, and because the link(2) syscall to create hard links does not work on directories, the st_nlink reference counter may never be >= 1 on a directory. In Perl5, the container types: hashes, lists (arrays), and anonymous subroutines may all have multiple references which point to the same underlying object. Merely allowing multiple references to the same object allows the possibility of a cycle. Oh well... But still (at least nowadays), I'd rather deal with this caveat in Perl5 than the complexity and/or unpredictability of GC.