github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nine Ha! My whole god damn Inline::Perl5 threading issue boils down to: do not load modules concurrently. 11:38
Which is something that I have suspected from the start. What I didn't take into account is that DBIx::Class will load a couple of modules (like DBD::Pg or its storage backend) on-demand when creating the first database connection. 11:39
nwc10 and things blow up where/how? 11:40
nine Since it's threading related, the errors look differently every time. But they are all compilation failures of the kind "Can't locate object method "mk_group_accessors" via package "DBIx::Class::Storage" 11:42
Or "Undefined subroutine &DBIx::Class::Storage::BlockRunner::reftype called" or it suddenly no longer knowing Moose's "extend" function 11:43
String found where operator expected at /usr/lib/perl5/vendor_perl/5.28.1/DBIx/Class/Storage/BlockRunner.pm line 49, near "qsub '$ENV{DBIC_STORAGE_RETRY_DEBUG}'"
Actually that's really all about missing some symbol
nwc10 I'm a bit confused. By "concurrently" does this mean that you've got two different OS threads trying to do stuff in the same Perl 5 interpreter at the same time? 11:44
lizmat that would be bad
nine No, in different ones
lizmat but Perl 6 thinking that they'd be available in all Perl 5's interpreters ? 11:45
nine This is my test script: gist.github.com/niner/d2dee661dbaa...e7262898ee
Each MoarVM thread gets its own Perl 5 interpreter to run code on. No data is being shared between them. 11:46
nwc10 OK, if I'm still confused, it's because if that's right, then surely each Perl 5 interpreter is completely unaware of any other interpreters, so should manage to stay self consistent
nine exactly!
nwc10 which seems to imply that this is a Perl 5 bug, somehow 11:47
nine Honestly it's starting to look more and more like that
nwc10 in that something is in Perl 5 global state that should not be. Or something that is there, isn't locked properly
lizmat Q: was all of Bart Wiegmans' work reverted to get Rakudo HEAD spectesting clean again ? 14:00
jnthn lizmat: I thought that what got reverted was some templates timotimo added, which ran into trouble? 14:02
lizmat I'm unsure, hence my question :-)
jnthn that's my recollection, and `git log --grep=revert` seems to agre 14:03
lizmat ok, *phew*
jnthn It looks like just several templates that were reverted
Yeah, 6 in total 14:04
nine nwc10: I managed to reproduce the failures with a plain C program embedding perl. Intriguingly they only happen when I load the full Atikon::DB::Timemngt schema, not when I load just DBIx::Class. 14:40
nine And now I can reproduce it with just XLM::LibXML 15:16
nine Surprisingly it boils down to IO::Handle! 15:32
nwc10 nine: this sounds nuts. How has this bug kept itself hidden for so long? 18:32
jnthn nwc10: If it requires embedding (which iiuc is still part of what nine has) I guess there's only so many things doing that, and doubly so if it depends on multiplicity. 20:44

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!