You are mixing two things: callback and asynchronous processing (in the sense of multi tasking), which work well together but are not bundled. That's why you are confused.

First of all callbacks should be non-blocking to allow multi tasking and your sleep is blocking by definition.

Think of callbacks as delayed execution, which are triggered by an event instead of executing things in a linear way.

(like adding tasks to a To-do list, like post-its on your fridge)

But it's the event management outside of the callback which allows multitasking.

The event management is deciding how to prioritize and bundle tasks on a To-do list and checking for urgent things from the Inbox...

(A call from hospital might be more important than repairing the lawnmower...)

Pushing a button in a GUI is such an event, but to be able to react the main program must be waiting for such an event instead of being blocked by longer execution or a sleep.

(you might miss telephone while working too long in the garden)

And while it's waiting it can call other callbacks from a queue which need to guaranty to run so fast that reacting to an event isn't hindered.

That's roughly the model of collaborative multitasking.

In a non-collaborative model sleep is implemented in a way to freeze a callback (read thread) and return control to the event manager who can continue the frozen thread later.

(Ideally a thread can be frozen nearly instantly after short running atomar steps, like finishing a page in a book and putting a bookmark)

But Perl isn't optimized for the latter and would need modules like AnyEvent to do so

HTH!

updates

1. callbacks are not necessarily non-blocking, they can simply be a comfortable way to define actions like in grep or File::Find . No real relation to multi threading here.

2. you mentioned fork, thats the non-collaborative way to allow multi-tasking on the OS level. Beside overhead (the whole perl process might be copied) it also involves the need of inter process communication.