| Re: Correlating curl resources to some other object. [message #185100 is a reply to message #185099] |
Wed, 26 February 2014 17:07   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 2/26/2014 11:54 AM, Daniel Pitts wrote:
>
> I may have up to a few dozen curl handles (from curl_init()), which I'm
> passing off to curl_multi etc... to make in parallel. As requests
> finish, I'm using curl_multi_info_read to figure out which curl handle
> completed. I have other objects which have additional information about
> the curl handles which I need in order to process them.
>
> I'm disappointed to see there isn't an equivalent to spl_object_hash for
> resources.
>
> In any case, it looks like casting a resource to a string results in a
> unique identifier [1], but the manual also states that the structure is
> "subject to change". I interpret that as it will still be unique (at
> least for that resource type), but it may be in a different format.
>
> So, I'm wondering if using the (string) cast of a Resource as an array
> key is going to lead to unexpected bugs during some future PHP upgrade.
> I'd rather not loop through all my objects to find the matching one.
> It's a small enough set that I might do that if there isn't another
> reliable way to achieve this, but I'd rather have an O(1) solution.
>
>
> Thanks,
> Daniel.
>
>
> References:
> [1]
> < http://us3.php.net/manual/en/language.types.string.php#language.types.strin g.casting>
>
Daniel,
I don't think there is a guarantee that casting a resource to a string
results in a unique string (although it does seem to work this way
currently). But I don't see anywhere in the documentation where it is
stated that is the case, so I wouldn't bet on it, now or in the future.
For instance, you may create a resource, save it's id as a string
("Resource id #1") then delete the resource. What happens if you now
create a new resource? Does it get "Resource id #1" - or something
else? What will happen in that case is not documented.
And while you say you wouldn't do that - what about two years from now
when you (or someone else) gets in and changes the code? Or what if,
due to some error, a resource is deleted by the system and another with
the same id allocated? These are all questions you should be asking
yourself.
Looping through the resources shouldn't be that hard or time consuming.
I agree a hash would be better, but until there is a guarantee the id
will always be unique in the particular run of a script, I wouldn't plan
on it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]