Re: Devel::Callsite is a better instance key than join $;,caller()[1,2]
On Fri, 8 Aug 2008 23:41:17 +0100 Ben Morrow [EMAIL PROTECTED] wrote: BM Just use the interpreter address: it's more unique than either pid or BM tid, and actually reflects 'Perl-level thread of control'. I would say BM that a second function in D::C (what, two whole functions in one module? BM Shocking!) to return the interpreter address would be the way to go. Is this a decent implementation? IV context() CODE: RETVAL = PTR2UV(Perl_get_context()); OUTPUT: RETVAL It seems *too* simple so I must be forgetting something. I get paid by the number of CPAN modules released, so yes, this will be Devel::GetContext, one function per module :) BM If you want calls to every(5) to only return true once every five times BM even across forked processes, your going to need some sort of IPC, BM obviously. It's actually not hard to do, just tie the hash to a shared memory segment with Tie::ShareLite and ignore the $$ and context() uniqueness. But I really doubt Every.pm should provide it, it's a solution in search of a problem. Ted
Re: Devel::Callsite is a better instance key than join $;,caller()[1,2]
On Wed, Aug 13, 2008 at 3:09 PM, Ted Zlatanov [EMAIL PROTECTED] wrote: I get paid by the number of CPAN modules released, so yes, this will be Devel::GetContext, one function per module :) I laughed BM If you want calls to every(5) to only return true once every five times BM even across forked processes, your going to need some sort of IPC, BM obviously. It's actually not hard to do, just tie the hash to a shared memory segment with Tie::ShareLite and ignore the $$ and context() uniqueness. But I really doubt Every.pm should provide it, it's a solution in search of a problem. it depends how far out you want your everyness context to extend, one might want to every on a condor cluster or something.
Re: Devel::Callsite is a better instance key than join $;,caller()[1,2]
Quoth [EMAIL PROTECTED] (David Nicol): On Fri, Aug 8, 2008 at 5:41 PM, Ben Morrow [EMAIL PROTECTED] wrote: [the interpreter address is] more unique than either pid or tid, and actually reflects 'Perl-level thread of control'. I'm a little surprised; I thought that the interpreter address would remain the same in both processes after a 'nix fork. Err, yes, it will. I assumed when Ted mentioned $$ he was talking about Win32's pseudo-fork, which will create a new interpreter with a new address. If you want calls to every(5) to only return true once every five times even across forked processes, your going to need some sort of IPC, obviously. Ben -- Although few may originate a policy, we are all able to judge it. Pericles of Athens, c.430 B.C. [EMAIL PROTECTED]
Re: Devel::Callsite is a better instance key than join $;,caller()[1,2]
Quoth [EMAIL PROTECTED] (Ted Zlatanov): You're probably right. I was thinking as a user of the module (with Every.pm), thanks for pointing this out. From thrtut, it seems that threads-self()-tid() will return the thread ID, and of course $$ is the PID. Is there a one-liner that will DTRT whether threads are loaded or not? I couldn't find one, so the usage example may have to be a little more complex. Just use the interpreter address: it's more unique than either pid or tid, and actually reflects 'Perl-level thread of control'. I would say that a second function in D::C (what, two whole functions in one module? Shocking!) to return the interpreter address would be the way to go. Ben -- I touch the fire and it freezes me, [EMAIL PROTECTED] I look into it and it's black. Why can't I feel? My skin should crack and peel--- I want the fire back... BtVS, 'Once More With Feeling'
Re: Devel::Callsite is a better instance key than join $;,caller()[1,2]
On Thu, 7 Aug 2008 14:04:24 -0500 David Nicol [EMAIL PROTECTED] wrote: DN On Thu, Aug 7, 2008 at 11:01 AM, Ted Zlatanov [EMAIL PROTECTED] wrote: I plan to add the interpreter (Perl context, actually) address when I get a chance, Ben Morrow was kind enough to point out what I was missing. Then it will be more correct than the current version. Does anyone know if the context address is unique in mod_perl and with threads? If not, what can I do? DN it seems like if it isn't, extending the instance key using the pid DN and tid would be best made the application developers problem. DN Suggesting an approach in the Devel::Callsite documentation by DN providing example code that produces an instance key that will be DN valid in forking and threading environments, would make more sense IMO DN than spoiling Devel::Callsite's focus. You're probably right. I was thinking as a user of the module (with Every.pm), thanks for pointing this out. From thrtut, it seems that threads-self()-tid() will return the thread ID, and of course $$ is the PID. Is there a one-liner that will DTRT whether threads are loaded or not? I couldn't find one, so the usage example may have to be a little more complex. Ted
Devel::Callsite is a better instance key than join $;,caller()[1,2]
=head1 NAME Devel::Callsite - Get current callsite =head1 SYNOPSIS use Devel::Callsite; sub $site { return callsite() }; print $site-(), \n; # prints one number print $site-(), \n; # prints a different number =head1 DESCRIPTION This function returns the callsite (a number) one level up from where it was called. See the tests for an example. It's useful for functions that need to uniquely know where they were called, such as Every::every() (see CPAN for that module). =head1 HISTORY Written by Ben Morrow on perl5-porters. CPAN-ified by Ted Zlatanov. =head1 AUTHOR Ben Morrow [EMAIL PROTECTED] Ted Zlatanov [EMAIL PROTECTED] =cut -- don't let the perfect become the enemy of the good -- some politician on CNN
Re: Devel::Callsite is a better instance key than join $;,caller()[1,2]
I plan to add the interpreter (Perl context, actually) address when I get a chance, Ben Morrow was kind enough to point out what I was missing. Then it will be more correct than the current version. Does anyone know if the context address is unique in mod_perl and with threads? If not, what can I do? Ted
Re: Devel::Callsite is a better instance key than join $;,caller()[1,2]
On Thu, Aug 7, 2008 at 11:01 AM, Ted Zlatanov [EMAIL PROTECTED] wrote: I plan to add the interpreter (Perl context, actually) address when I get a chance, Ben Morrow was kind enough to point out what I was missing. Then it will be more correct than the current version. Does anyone know if the context address is unique in mod_perl and with threads? If not, what can I do? Ted it seems like if it isn't, extending the instance key using the pid and tid would be best made the application developers problem. Suggesting an approach in the Devel::Callsite documentation by providing example code that produces an instance key that will be valid in forking and threading environments, would make more sense IMO than spoiling Devel::Callsite's focus. -- don't let the perfect become the enemy of the good -- some politician on CNN