| Re: Correlating curl resources to some other object. [message #185104 is a reply to message #185101] |
Wed, 26 February 2014 18:52   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 2/26/2014 12:52 PM, Daniel Pitts wrote:
> 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'
>
That could be read two ways. For instance, if a resource is destroyed,
creating a new resource could have the same number. It would still
identify a unique *valid* resource.
> Of course, it then says don't rely on that structure. Grr.
>
Yes, as I said, I agree it seems to always be a unique value (it
increments one for each resource created). But nothing says it will
remain so, and the doc seems to indicate the opposite.
Of course, it could also mean don't rely in it being exactly "Resource
id #1" - but later could be something like "curl resource #1", "mysql
resource #2", or even just "curl 1" - but still unique. The doc is not
at all clear on this. I would like to see a clarification on this
point, for just the reasons you've stated.
>> 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.
Sorry, youngster (I've probably been in the industry longer than you've
been alive :) ). I'm not trying to insult you here. But I have to
constantly remind myself of these same things.
>>
>> 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 guess you *could* create an array with the key being the string
conversion of the resource, and the value being a reference to the curl
resource. Before inserting a new entry into the array, check to see if
it already exists. If it does, log an error. Be sure to comment your
code well so if you get the error 2 years from now you know what it
means (it's amazing how short our memories can be! :) ).
> I wonder if a feature request to support an "spl_resource_hash" would
> get any traction.
>
>
I would support some kind of truly unique identifier which could be used
as a key. Whether it is an spl_resource_hash or something else makes
little difference, as long as it's useful.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]