Re: "open" Best Practices

Perhaps mention something about paying attention to the ownership and permissions on newly created paths and files, and to consider the ramifications of locking (or failing to do so). So often we envision our solutions in terms of simple development environments not considering that there's a real world where processes can compete with each other over the same resource, or where not everyone is the same person as $ENV{'USER'}, and so on. At minimum, if our code is expected to be the only instance of itself running (so that it's not competing for a resource with other instances of itself) are we doing anything to assure it is the only instance? Have we considered that someone might be writing to, unlinking, moving, copying, reading from the same file we're working with?

Using open correctly is the easy part.

Dave

Comment on Re: "open" Best Practices Download Code

Replies are listed 'Best First'.
Re^2: "open" Best Practices by eyepopslikeamosquito (Archbishop) on Jul 12, 2019 at 08:56 UTC
Yes, making the code robust in the face of (perhaps rare) environmental conditions, such as a power failure or the user pressing CTRL-C while the program is running can be surprisingly tricky to get right. Two examples I remember are: Perl Best Practices book: is this one a best practice or a dodgy practice? Re: Lock File	[reply]
Re^2: "open" Best Practices by haukex (Archbishop) on Jul 12, 2019 at 16:26 UTC
Using open correctly is the easy part. Yes, and hence my relatively short node - I really just wanted to focus on the `open` statement itself, so I'd have something to link to in posts like this one. But I've added a mention of your suggestion to the root node, thanks!	[reply] [d/l]
Re^2: "open" Best Practices by karlgoethebier (Abbot) on Jul 12, 2019 at 13:30 UTC
"...the easy part." Well said. Some callow thoughts about some situations when things get a little bit harder: I just wondered if some ugly locking stuff could be handled with `mce_open` from MCE::Shared::Handle. Probably this may be yet another case of total abuse of a module. And testing with `lsof` if a file is in use might be an option from time to time as well. Best regards, Karl ŤThe Crux of the Biscuit is the Apostropheť `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l] [select]
Re^3: "open" Best Practices by marioroy (Prior) on Jul 14, 2019 at 16:39 UTC
Hi karlgoethebier, The mce_open call behaves similarly to the native open in Perl. It creates a shared handle with exclusive locking handled transparently. Example: use strict; use warnings; use feature 'say'; use MCE::Hobo; use MCE::Shared; # Passing a file ref without IO::FDPass will work for \STDIN, # \STDOUT, \STDERR, and \main::DATA only. Otherwise, providing # the actual path is preferred (i.e. "/path/to/file"). mce_open my $out, '>>', \STDOUT or die 'open failed: $!'; mce_open my $err, '>>', \STDERR or die 'open failed: $!'; printf $out "shared fileno(\$out) is %d\n", fileno($out); printf $out "shared fileno(\$err) is %d\n", fileno($err); if ($^O ne 'MSWin32') { mce_open my $log, '>>', '/dev/null' or die 'open failed: $!'; say $log "Hello, there!"; # sent to null } # The shared-handles work with threads, MCE::Hobo, MCE::Child, # Parallel::ForkManager, and other parallel modules on CPAN. # Note: There is no reason to choose MCE::Child over MCE::Hobo # if already involving the shared-manager. sub foo { my ($id) = @_; say $out "Hello, from pid $$"; } MCE::Hobo->create('foo', $_) for 1..4; MCE::Hobo->wait_all; [download] Output: `shared fileno($out) is 1 shared fileno($err) is 2 Hello, from pid 4651 Hello, from pid 4652 Hello, from pid 4653 Hello, from pid 4654` [download] See also: https://metacpan.org/pod/MCE::Shared#DBM-SHARING https://metacpan.org/pod/MCE::Shared#LOGGER-DEMONSTRATION Regards, Mario	[reply] [d/l] [select]