|more useful options|
I keenly (and painfully) remember getting segfault after segfault with threads::shared on distributed cluster of rhel 5 servers I had to work with about 6 months back. I eventually gave up and just used stock threads. The application was about 2K lines and I wasn't about to try to find out why threads::shared wouldn't work...everything looked fine, and I was following all the rules. What's more, I needed to share some very complex datastructures (I believe the real problem was exactly that, and it was an uncompromising requirement). I got around the segfaults by using a not-so-elegant fix (Storable::lock_store / Storable::lock_retrieve on a ramdisk). I'm not proud of that, but it worked and it's been running in production as a persistent service for worldwide venues going on several months now -- no memleaks, no segfaults, no problems. It had to be done to get it to work on the old rhel 5 platforms.
I chocked it up to having a perl that was too old when the same code ran fine on my own servers which had the most recent stable perl. I made a mental note that in the future I would need to be more careful with threads::shared (or avoid it entirely) when writing code that might need to run on legacy servers.
Just my own personal experience; YMMV
I appreciate the time you took in coding that example for me. I don't take it lightly that you freely gave your own valuable time to do that. Thank you.
$ perl -MMIME::Base64 -e 'print decode_base64 "YWNlQHRvbW15YnV0bGVyLm1lCg=="'