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


Groups > comp.lang.php > #12998

Re: Correlating curl resources to some other object.

From Jerry Stuckle <jstucklex@attglobal.net>
Newsgroups comp.lang.php
Subject Re: Correlating curl resources to some other object.
Date 2014-02-26 12:07 -0500
Organization A noiseless patient Spider
Message-ID <lel700$ffi$1@dont-email.me> (permalink)
References <X_oPu.5301$8L3.968@fx32.iad>

Show all headers | View raw


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).  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@attglobal.net
==================

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