Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #12999

Re: Correlating curl resources to some other object.

Show all headers | View raw

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.string.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.

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Correlating curl resources to some other object. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-02-26 08:54 -0800
  Re: Correlating curl resources to some other object. Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 12:07 -0500
    Re: Correlating curl resources to some other object. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-02-26 09:52 -0800
      Re: Correlating curl resources to some other object. Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 13:52 -0500
        Re: Correlating curl resources to some other object. Adam Harvey <usenet@adamharvey.name> - 2014-02-26 21:25 +0000
          Re: Correlating curl resources to some other object. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-02-26 13:48 -0800
          Re: Correlating curl resources to some other object. Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 17:22 -0500
        OT: getting older/wiser bill <william@TechServSys.com> - 2014-02-27 07:04 -0500
          Re: OT: getting older/wiser Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 08:22 -0500
            Re: OT: getting older/wiser bill <william@TechServSys.com> - 2014-02-27 11:02 -0500
            Re: OT: getting older/wiser Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-02-27 09:11 -0800
              Re: OT: getting older/wiser Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 18:52 +0100
              Re: OT: getting older/wiser Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 16:20 -0500
              Re: OT: getting older/wiser Allodoxaphobia <knock_yourself_out@example.net> - 2014-02-27 23:56 +0000
                Re: OT: getting older/wiser Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-02-28 19:08 -0800
                Re: OT: getting older/wiser Colin Birch <colin@ihatespamrailscans.co.uk> - 2014-03-01 13:37 +0000
                Re: OT: getting older/wiser Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-03-02 12:51 -0800
            Re: OT: getting older/wiser Tim Streater <timstreater@greenbee.net> - 2014-02-27 18:01 +0000

csiph-web