If the worker does not share data with the main program, it is probably best to fork it off as a child process.

Threads are expected to behave nice, as they can write shared data, terminate the whole process with an exec, etc. Implementing the blocking/timeout logic in a thread itself should be preferable. In any case, threads i.e. clones share signal dispositions (signal handlers), so extra care should be taken when mixing threads and signals.¹ (Don't use alarm.)

That said, you can work around the problem by using Thread::Queue and a baby-sitter.

#! /usr/bin/perl

use strict;
use warnings;
use Data::Dumper;

use threads;
use Thread::Queue;

my $Q = Thread::Queue->new();
sub manage {
    async{ $Q->enqueue({ $_->tid => $_->join }) }->detach for @_
}

sub worker {
    print "Worker started.\n";
#    1 while 1;
    return 42;
}

manage( threads->create(\&worker) );

print Dumper $_ for $Q->dequeue_timed(2);
[download]

1) Update. Perl will dispatch signals, thus threads can have their separate handlers. But not a mix of 'IGNORE'/'DEFAULT'/code. It also appears that most signals are blocked in threads; to get around this, one might use POSIX::sigprocmask. But it's hopeless anyway: alarm is per-process.
Correction: Just blocking the ALRM in main thread (after thread creation) allows another thread to catch it. I don't know if this can be relied on...