| Re: Correlating curl resources to some other object. [message #185101 is a reply to message #185100] |
Wed, 26 February 2014 17:52   |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma:
|
Member |
|
|
On 2/26/14 9:07 AM, Jerry Stuckle wrote:
> 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).
The documentation *does* say it is a unique string.
'Resources are always converted to strings with the structure "Resource
id #1", where 1 is the unique number assigned to the resource by PHP at
runtime'
Of course, it then says don't rely on that structure. Grr.
> 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.
Sometimes I have to remind myself that you're writing for a larger
audience, and not take your suggestions as a lack of respect for me ;-)
I've been working in the industry for 10+ years now, and have been
playing around with software for 25+ years. So I have definitely
learned to ask those questions on a regular basis.
>
> 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.
I suppose. We're talking on the order of 100 items, so that's an
average of 5000 comparisons to completely process the entire set.
Actually, that's worse case, so I should be fine.
I wonder if a feature request to support an "spl_resource_hash" would
get any traction.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]