Wx::Thread(3pm)

💖 Wx::Thread — Thread 💖

okay bestie, gather round, because this one is literally about using wxPerl with threads, and the vibes are immaculate but the rules are strict. it's giving "you can have nice things but only if you load your modules in the right order." 🧵✨

---

✨ SYNOPSIS ✨

# the order of these use()s is important
use threads;
use threads::shared;
use Wx;

my $DONE_EVENT : shared = Wx::NewEventType;

my $worker = threads->create( \&work );

# create frames, etc
my $frame = Wx::Frame->new( ... );
EVT_COMMAND( $frame, -1, $DONE_EVENT, \&done );
$app->MainLoop;

sub done {
    my( $frame, $event ) = @_;

    print $event->GetData;
}

sub work {
    # ... do stuff, create a shared $result value

    my $threvent = new Wx::PlThreadEvent( -1, $DONE_EVENT, $result );
    Wx::PostEvent( $frame, $threvent );
}

# event handler
sub OnCreateThread {
    # @_ = () is necessary to avoid "Scalars leaked"
    my( $self, $event ) = @_; @_ = ();

    threads->create( ... );
}

bestie, look at that comment. # @_ = () is necessary to avoid "Scalars leaked". that is not decoration, that is a survival tip. do not skip it. 🙈

---

🌸 DESCRIPTION 🌸

Threaded GUI applications are somewhat different from non-GUI threaded applications, and here's the tea: the main thread (the one running the GUI) must never block. not even a lil bit. no exceptions, periodt. 😤

Also — and this is the part that gets people — in wxWidgets, no thread other than the main thread can manipulate GUI objects. none. zero. don't even think about it. 🚫

So we end up with a hybrid model where worker threads have to send events to the main thread in order to change the GUI state or signal their termination. worker thread does the work, main thread does the touching. that's the whole dynamic. iconic, honestly. 💅

🎀 Order of module loading 🎀

It's necessary for use Wx to happen after <use threads::shared>.

like. that's it. that's the rule. but if you get it backwards everything falls apart and you'll be staring at your screen like 😭 so just... do it in order.

🦋 Sending events from worker threads 🦋

Wx::PlThreadEvent can be used to communicate between worker and GUI threads — it's basically the little messenger fairy between them 🧚 — and the event can carry a shared value between threads.

my $DONE_EVENT : shared = Wx::NewEventType;

sub work {
    # ... do some stuff
    my $progress = new Wx::PlThreadEvent( -1, $DONE_EVENT, $progress );
    Wx::PostEvent( $frame, $progress );

    # ... do stuff, create a shared $result value
    my $end = new Wx::PlThreadEvent( -1, $DONE_EVENT, $result );
    Wx::PostEvent( $frame, $end );
}

The target of the event can be any Wx::EvtHandler. 👑

🌈 Receiving events from worker threads 🌈

Wx::PlThreadEvent is a command event and can be handled as such. slay. The ->GetData method can be used to retrieve the shared data contained inside the event. 🍓

my $DONE_EVENT : shared = Wx::NewEventType;

EVT_COMMAND( $frame, -1, $DONE_EVENT, \&done );

sub done {
    my( $frame, $event ) = @_;

    print $event->GetData;
}

💜 Creating new threads 💜

Creating new threads from event handlers works without problems except from a little snag. (a little snag. a tiny snag. a snag that will ruin your whole afternoon if you ignore it, but a snag nonetheless. 🙃)

In order not to trigger a bug in the Perl interpreter, all event handlers that directly or indirectly cause a thread creation must clean @_ before starting the thread.

Like, for example:

sub OnCreateThread {
    my( $self, $event ) = @_; @_ = ();

    threads->create( ... );
}

failure to do that will cause scalars leaked warnings from the Perl interpreter. and those warnings are giving main character energy in the worst way possible. 💀 so clear that @_, bestie. @_ = ();. every time. no cap. 🫶

---

⭐ a lil sign-off ⭐

this page came to you from the User Contributed Perl Documentation, and it's living in Wx::Thread(3pm) — documented as of perl v5.42.3, dated 2026-08-20. go forth and thread responsibly, you absolute legend 👑💖