Nothing strange at the return codes of the subs.

That doesn't make much sense. At the very least, I would expect to see the output from

"$capobj breakloop\n";
[download]

If that is not being output, then it suggests that breakloop() is never returning, which is a Pcap issue rather that anything to do with threads.

The callback part works perfectly, i've just remove the contents for the test

Since you creating $capobj in your main thread and using successfully with the capture thread, it suggests that the sharing is working fine.

I've try it sharing, passing as a parameter to the thread (don't know why it makes a local copy too instead of using the same by reference), i've tried too the last 2 options but using references and found that althoug the references are being copied (as i expected) the content of the references changed too to the copied values inside the thread instead of pointinng to the original variable at the main thread.

That's a red-herring. The addresses shown in the printout are the addresses of the references not the thing it points to. The way sharing works it to create a clone specific to each thread that acts as a proxy for the real data.

The notation package=TYPE(address) means that this reference is located in memory at adddress, it points to a variable of type TYPE, and it is bless'd into package. So your output simply means that each of your two threads has it's own reference to the object:

THREAD 1:                     THREAD 2:
pcap_tPtr=SCALAR(0x8ee08f8)   pcap_tPtr=SCALAR(0x8f223b4)
¦                                                        ¦
¦                                                        ¦
+-----------> A perl scalar that <<----------------------+
              holds the address 
              of the pcap struct:
              0xxxxxxxxx
              ¦
              +---> Whatever that struct looks like
[download]

I still suggest that you print the return codes of the calls, switch to using warn and put some trace in the callback.