in reply to Re^4: Perl/Tk code structure
in thread Perl/Tk code structure
It turns out that if I have something like open(LOG, ">:encoding(UTF-8)", "$scriptpath/scripts/log.txt") or print "\nCan't create log file: $!\nContinuing anyway.\n"; before the .pm is loaded, it crashes. (It works if I remove ">:encoding(UTF-8)", but that's hardly ideal.)
It appears that the unicode IO layers are not thread-safe. I cannot help you with that, you'll have to raise a bug report.
The work around is to not open your logfile until after you've decided whether to invoke the GUI or not.
If you find that too restricting, then open the logfile without the encoding layer before making the decision and binmode the io layer on afterward:
#! perl -slw use strict; use threads; our $GUI //= 0; open LOG, ">", "$0.log" or print "Can't create log file: $!"; if( $GUI ) { require 'MyGui.pm'; async( \&MyGui::gui )->detach; } else { binmode STDIN, ':encoding(UTF-8)'; } binmode LOG, ':encoding(UTF-8)'; while( 1 ) { printf 'Enter three, 2-digit numbers: '; my $in = scalar <STDIN>; last if $in =~ '!bye'; print 'You entered: ', $in; printf 'Enter a date and time: '; $in = scalar <STDIN>; last if $in =~ '!bye'; print 'You entered: ', $in; }
I also have binmode STDIN, ':encoding(UTF-8)'; at the start of the script, which also crashes the GUI (IIRC it was needed for non-ASCII input file names to work on linux).
If you are using the gui, then you will not actually be using STDIN, as the input will come via Tk. So, only binmode stdin if you are not using the gui, as shown above.
From what I can tell, the thread-hostility of the unicode IO layers is not a some subtle error involving race conditions or mismatched locking, but rather a complete absence of any attempt on behalf of the code to be thread-safe. Just plain, old-fashioned bad coding.