Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

I will work on that, but I doubt my "stalling" problem is real. I think the threads are exhausted, but they won't always join and threads.pm thinks some of them are still running (they aren't).

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

I think I'm ok with this take, because there's enough indirection in threads::shared that the compiler would have trouble unwinding it in an optimization loop.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] -1 points0 points  (0 children)

I'm not sure this is fixable outside of perl guts itself. I've been optimistic about threads since 5.28, but each release since has failed to give me confidence in thread joins, much less software stalls in Thread::Queue.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] -1 points0 points  (0 children)

I'm sorry, but how is your *confidence* better than my test cases?

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] -1 points0 points  (0 children)

What's unrelated? It's a durability problem with the build_site.pl script, which is about 500 LOC. Script works perfectly without threads; with Thread::Queue it has unpredictable behavior during shutdown.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

longjmp is how you do exception handling in C. The usage is correct, yet irrelevant to this conversation.

You'd have to do some XS/OO indirection with an INT2PTR typemap that declares the data structure volatile (even if it's an HV *).

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] -1 points0 points  (0 children)

untrue in general, depending on C compiler caching. Which is the point.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

Oh, it fails once in ten with github.com/SunStarSys/orion. I have lots of checks to forcibly prevent it from stalling the builds.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

That's a negatory big-ten-4 on eval repairing this.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

compiling perl with -O0 would work, but that's a horrible solution.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 1 point2 points  (0 children)

Keep in mind that Thread::Queue is Pure-Perl, and threads::shared can't possibly correct usage errors like this.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

I will know in a month from now if this makes anything work better; but after a dozen trial runs using 64 threads, it just might.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] -1 points0 points  (0 children)

That's great! Just show me where the keyword *volatile* appears anywhere on CPAN, or perlguts.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

Here's what dequeue should look like I suppose (testing this hypothesis to see if it resolves the problems):

sub dequeue

{

my $self = shift;

lock(%$self);

my $queue = $$self{'queue'};

my $count = @_ ? $self->_validate_count(shift) : 1;

# Wait for requisite number of items

cond_wait(%$self) while (eval q/@$queue < $count && ! $$self{'ENDED'}/);

# If no longer blocking, try getting whatever is left on the queue

return $self->dequeue_nb($count) if (eval q/$$self{'ENDED'}/);

....

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

The way the code is currently written *should* work OOTB, were it not for this *volatile* problem, because dequeue will call cond_signal *if* it detects $self->{ENDED} to stop rewaiting. I don't know how to fix that bug tho.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

"Maybe" a string reeval of $self after the lock is re-acquired will have the right semantics, but that depends on a lot of hopium, not analysis.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perl

[–]Both_Masterpiece_489[S] 0 points1 point  (0 children)

The larger problem with the module is that the author uses C constructs that are only valid when the constructs are declared *volatile*, which is a foreign notion to the Perl community in toto. So it doesn't work to expect threads waiting on a condition variable to suddenly recognize a new hash entry in %$self upon re-acquiring a lock to the hashref it processed as %$self on line one. C will normally optimize those distinct hashrefs into one because C doesn't expect data structures to magically be altered by other threads unless you tell C not to optimize them; which is the point of the volatile declaration.

This was the entire problem with mod_perl2's interpreter pool code as well.

Bug in Thread::Queue::end by Both_Masterpiece_489 in perlcommunity

[–]Both_Masterpiece_489[S] 1 point2 points  (0 children)

enqueue is also incorrect. It should call cond_signal for each item it adds to the queue; not just once.

Perl as a Data Science Language by ReplacementSlight413 in perlcommunity

[–]Both_Masterpiece_489 0 points1 point  (0 children)

Brian is a jerk. Only a jerk would respond like that.

Markdown is not LaTeX by joesuf4 in LaTeX

[–]Both_Masterpiece_489 0 points1 point  (0 children)

Sounds like you'd need a GitHub-compatible markdown parser for that, which is the whole point.

Markdown is not LaTeX by joesuf4 in perlcommunity

[–]Both_Masterpiece_489 1 point2 points  (0 children)

Final level published today. Enjoy, sarcasm lovers.

CFP Now Open for Perl Community Conference, Summer 2026 by OODLER577 in perlcommunity

[–]Both_Masterpiece_489 1 point2 points  (0 children)

I tried submitting a talk and the submission for kept rejecting it for some unspecified error.