New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify (or fix) the semantics of Oo.id #5436
Comments
Comment author: @garrigue For the second point, this is oops! : indeed ids should be fresh upon unmarshaling. For the first point, we have to check the code. |
Comment author: @garrigue For point 1, ids are guaranteed to be different in different threads: For point 2, indeed the behavior was incorrect, and ids were not updated when unmarshaling. |
Comment author: @alainfrisch I've added some words of warning the documentation for Oo.id. |
Comment author: @xavierleroy I agree with Jacques that we should probably move the generation of fresh IDs to C code, to simplify unmarshaling and to provide clear atomicity guarantees. |
Comment author: @dbuenzli Would it be possible to also expose the unique id generation as a function in pervasives or Sys ? That's a useful function beyond ids for objects. I use the id of empty objects as thread safe runtime unique ids in more than one program to implement the keys of type safe heterogenous dictionaries (on Alan's F. suggestion btw. [1]). let ruid () = Oo.id (object end) This would avoid linking against Oo in these programs. Best, Daniel |
Comment author: @garrigue To xleroy: let set_id o id = Is there any risk of race? Before doing that, I tried a version with id generation on the C side, but I was afraid that this would make object creation slower. If you think this wouldn't have any impact, I'll revert to that solution. By the way, if the code generating ids in CamlinternalOO is already safe, there is clearly no need to include CamlinternalOO to do that: you just have to duplicate the above 4 lines. |
Comment author: @dbuenzli
Oh right. You mean that what I thought was not thread-safe : let create = is in fact thread-safe because no allocation occurs between let id = !c, incr c and the conditional ? |
Comment author: @dbuenzli Still this would rely on an implementation detail, I'd prefer if something was given to me by the runtime system. |
Original bug ID: 5436
Reporter: @alainfrisch
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2013-08-31T10:48:51Z)
Resolution: fixed
Priority: normal
Severity: minor
Fixed in version: 3.13.0+dev
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @protz @dbuenzli
Bug description
It should be clarified how Oo.id behaves in the following cases:
Multi-threaded program: is it guaranteed that two different threads cannot create objects with the same id (I think so).
Serialized objects: currently, unmarshaling does not assign fresh ids to objects. It is thus possible to have two different objects in the same run of the program. Shouldn't unmarshaling reassign ids instead? One could then make clear in the documentation that Oo.id (and thus, generic hash/comparison) is not stable across "marshaling" boundaries, but at least one would keep the uniqueness property.
The text was updated successfully, but these errors were encountered: