Take the 2-minute tour ×

perldoc perl5150delta says:

   $$ can be assigned to
       $$ was made read‐only in Perl 5.8.0.  But only sometimes: "local $$"
       or XS code to bypass the read‐only check, so there is no reason to keep
       $$ read‐only.  (This change also allowed a bug to be fixed while
       maintaining backward compatibility.)

$$ is the current process ID, why in the world would you assign to it?

share|improve this question
Golf? Obfuscation? –  Chris Lutz Aug 8 '11 at 1:11
Supporting the day sometime in the uncertain future when POSIX is updated to provide a setpid() call? –  Donal Fellows Aug 8 '11 at 2:09
add comment

3 Answers

up vote 8 down vote accepted

There are only a couple (literally) places in CPAN where people want to assign to $$, and it's mostly for testing (I haven't understood IPC::Messaging yet). I don't like this feature, especially since there's a much better way to get the same effect. The Perl 5 Porters added this feature because they could and they would rather not make the couple of cases do a better job of testing. If you read the p5p thread, it's obvious that this feature wasn't driven by need.

I wrote about it in Hide low-level details behind an interface.

However, I could be wrong on this because I'm not that good at the low-level black magic. I know there is a need to coordinate PIDs, but so far I think that $$ isn't the only way to do that. If someone has a use case that they can explain to me, I'll update that post.

share|improve this answer
add comment

IPC::Messaging, which provides sorta kinda Erlang-like messaging (not performance-wise, syntax-wise) does that to $$ to replace it with an object which numifies to the original pid. This is done to have a convenient reference to a "self-process" which one can call methods on (= send messages to).

Full disclosure: I am the author of the module.

share|improve this answer
I looked at this module, and I don't really understand what you need to do (although I know what you are doing). Does any of the stuff I say in effectiveperlprogramming.com/blog/1196 apply in your case? If not, I'd like to understand why and update my post to show that sometimes you might need to assign to $$. :) –  brian d foy Aug 8 '11 at 20:30
brian, the module can spawn processes and send messages to them afterwards. A message send looks like a method call on a var representing a process: $proc1->message1(1,2,3);. Sometimes one wants to send message to the current process. I chose to make $$ an object so that the same syntax applies: $$->messageBlah(42);. It is by no means a hard requirement; a global var or a function call like this_proc()->messageBlah(42) would work just fine. But since $$ already has a strong association with "this process", such syntactical cuteness seemed appropriate, in the module's context. –  Grrrr Aug 8 '11 at 23:47
add comment

If you were the syscall implemenation of a fork() like system call you would need to assign to the global one.

share|improve this answer
You mean if the kernel were written in Perl? –  Heath Hunnicutt Aug 8 '11 at 1:15
No, I mean if the syscall gateway were written in perl. –  Joshua Aug 8 '11 at 1:16
@Joshua: then why was it made read-only at one point? Seems to me like if something critical like fork stopped reporting the right PID that would make quite a mess of things... –  Chris Aug 8 '11 at 1:28
@Heath - I assume that, in the code that implements fork, at some point after the fork you may need to modify the value of $$. Perl's built-in fork undoubtedly does this for you, but if your (XS) module calls the native-C fork rather than Perl's version, you'll need to do it yourself. –  Chris Lutz Aug 8 '11 at 1:28
@Chris Lutz But if you were in XS, you could muck with $$ anyway (you would have access to SvREADONLY_off). This change allows Perl code to muck with $$. –  Chas. Owens Aug 8 '11 at 1:35
show 1 more comment

Your Answer


