Skip Menu |

This queue is for tickets about the Class-Std CPAN distribution.

Report information
The Basics
Id: 14060
Status: new
Priority: 0/
Queue: Class-Std
People
Owner: Nobody in particular
Requestors: dagolden [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Important
Broken in: 0.0.4
Fixed in: (no value)
Attachments
Class-Std-thread-tests.tar.gz

History Show all quoted text
  Mon Aug 08 13:55:08 2005 dagolden [...] cpan.org - Ticket created
Subject: ID/refaddr and thread/fork safety
(This came up in a discussion on thread-safty on Perlmonks in reference to my module Object::LocalVars.) Using refaddr as the lookup key for inside-out data means that objects become disconnected from their data across thread creation (and, presumably forking), as the underlying memory location changes in the copy. Storing the original memory address in the blessed scalar reference and using that as a key should work, but might still have collision problems if the original reference is released and the memory location subsequently reused for another object. Using a truly unique identifier (UUID or equivalent) and storing that in the blessed scalar reference may be a safer solution.
  Sat Aug 20 17:48:04 2005 damian [...] conway.org - Correspondence added
Date: Thu, 18 Aug 2005 09:03:04 -0700
From: Damian Conway <damian [...] conway.org>
To: bug-Class-Std [...] rt.cpan.org
Subject: Re: [cpan #14060] ID/refaddr and thread/fork safety
RT-Send-Cc:
Show quoted text
>> (This came up in a discussion on thread-safty on Perlmonks in >> reference to my module Object::LocalVars.) Using refaddr as the >> lookup key for inside-out data means that objects become disconnected >> from their data across thread creation (and, presumably forking), as >> the underlying memory location changes in the copy. Storing the >> original memory address in the blessed scalar reference and using >> that as a key should work, but might still have collision problems if >> the original reference is released and the memory location >> subsequently reused for another object. Using a truly unique >> identifier (UUID or equivalent) and storing that in the blessed >> scalar reference may be a safer solution.
Would it not be enough to use the shared() subroutine from threads::shared to mark your objects as shared? Damian
  Sun Aug 21 09:18:04 2005 dagolden [...] cpan.org - Correspondence added
[damian@conway.org - Sat Aug 20 17:48:04 2005]: Show quoted text
> Would it not be enough to use the shared() subroutine from > threads::shared to > mark your objects as shared?
Unfortunately, not. As I understand it, sharing doesn't actually share a memory slot, but creates a tied variable that does "stuff" to make it look like things are shared. (c.f. http://perlmonks.org/index.pl?node_id=288022) I'm attaching two test cases that demonstrate the problem: one for regular threading and one for shared threads. Of course, since Win32 pseudo-forks do threading, you could write an equivalent fork-test and it would fail on Win32 platforms as well. I have developed a workaround for this thread problem with inside-out objects for perl 5.8+ using a "registry" of objects and a CLONE subroutine that remaps the data to the new refaddr upon cloning. This avoids the need to use a UUID or the like. Unfortunately, it increases the complexity and diminishes the elegance of inside-out objects and doesn't support sharing -- it only ensures data isn't lost across the thread creation boundary. However, for people using a framework such as Class::Std that takes care of these tricky details for them, this approach should be fine. The workaround is detailed on perlmonks here: http://perlmonks.org/index.pl?node_id=483162
Download Class-Std-thread-tests.tar.gz
application/x-gzip 844b

Message body not shown because it is not plain text.