Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Object IDs not persistent #1017

Open
Util opened this Issue · 3 comments

3 participants

@Util
Owner

Reported by: zefram@fysh.org

The get_id op is documented to return an ID for any object. The IDs returned don't actually function as IDs, because different ID values are returned from multiple calls for a single object. Specifically, the IDs seem to be per thread:

$ cat t60.pir
.sub foo
        $P0 = get_global "wibble"
        $S0 = typeof $P0
        say $S0
        $I0 = get_id $P0
        say $I0
        .return ()
.end
.sub main :main
        $P0 = new "ResizablePMCArray"
        set_global "wibble", $P0
        .const "Sub" foo = "foo"
        $P1 = new "Task", foo
        schedule $P1
        sleep 0.1
        $S0 = typeof $P0
        say $S0
        $I0 = get_id $P0
        say $I0
.end
$ ./parrot t60.pir
ResizablePMCArray
5106441376529261666
ResizablePMCArray
5106441376529297014

The two threads are apparently dealing with the same object, confirmed by them seeing it having the same type, but they get different IDs for it. This breaks most of the interesting uses for object IDs.

Observe that the example also falls within the scope of the documentation's guarantee about ID uniqueness: threads that share data, during the object's lifetime. Persistence of an object's ID is the counterpart to uniqueness, required to make the ID useful. (Indeed, required for it to qualify as an ID.)

-zefram

Summary of my parrot 5.7.0 configuration:
  configdate='Sat Oct  5 12:42:43 2013 GMT'
  Platform:
    osname=linux, archname=x86_64-linux-gnu-thread-multi
    perl=/usr/bin/perl
@Benabik
Collaborator

Perhaps those IDs are actually for proxy objects? Accessing data across threads is supposed to be done indirectly.

@rurban
Collaborator

Indeed, a read-only proxy of that data has a different ID for that object than the writable original object.
Yes, that's a bit unfortunate, it's a different object, a proxy to the actual object. But I agree with zefram that proxied object IDs should return the same ID since threads should be transparent in this regard.

@rurban
Collaborator

I've pushed a testcase for get_id to the branch rurban/gh1017-proxy-get_id but it is not working yet

@rurban rurban added this to the 7.0.0 milestone
@rurban rurban referenced this issue from a commit
@rurban rurban [ops] follow a proxy with get_id
Closes GH #1017
04b30a7
@rurban rurban modified the milestone: 7.1.0, 7.0.0
@rurban rurban modified the milestone: 7.2.0, 7.1.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.