Re: CFHTTPMessage and thread safety
Re: CFHTTPMessage and thread safety
- Subject: Re: CFHTTPMessage and thread safety
- From: "Bertrand Landry-Hetu" <email@hidden>
- Date: Fri, 29 Aug 2008 16:09:00 -0400
Short answer:
If I read correctly my usage pattern is pretty much what you describe
at end with the exception that I'm using 1 runloop per thread instead
of going back to the main thread.
Long: answer:
We have this desktop app that communicates with a server via XMLRPC
and we allow 2 concurrent XMLRPC requests. Each request is on its own
thread and each thread has its own message, stream and a runloop that
lives as long as it takes for that single request to finish. Mutation
only happen on threads that "own" their object.
Up to this point everything was working fine, but then we found all
those sockets that we were leaving open on the web server so I turned
on the persistent connection flag and then testers reported many
crashes on 10.4 and maybe one crash on 10.5. My guess was that the 2
threads where reusing connections created by the other thread or that
the connection cache itself was not thread safe (althought the
CFNetwork code from 10.4 does show some locking around the cache, too
bad the 10.5 code isn't open). I refactored my code to use only one
runloop on a background thread and now everything works fine.
If that is supposed to work, I'll try to build a test app to submit to radar.
2008/8/29 Mark Pauley <email@hidden>:
> Could you explain what you mean by this? Were you running into issues with
> persistent connections that were each used from a single thread? Or were you
> trying to set the persistent connection bit of a connection scheduled on one
> thread from another thread?
>
> As Quinn said, I would expect that CFHTTPReadStreamAPI is perfectly
> thread-safe as long as you're locking around access to individual streams or
> only using a given stream on a single thread. Remember that if you've got a
> stream scheduled on multiple RunLoops that you'll likely have to lock around
> the stream callback as well, since once you call CFReadStreamRead, your
> stream can get signalled with more events, which may cause you to reenter
> your stream callback (most people don't expect that sort of behavior).
>
> In particular, it should be absolutely fine to: create a stream on one
> thread and schedule it on another, or create a stream on one thread and
> schedule it on multiple threads, etc. Just make sure you do all of your
> property setting before you call open, or you may need to lock. You are in
> charge of locking around mutations, and you absolutely must lock around
> mutations of your client context. We have tests that use the API in the
> following fashion: spawn a bunch of threads, each thread creates a message /
> http stream and sets the Persistent Connection property on its stream. Then
> we schedule on the current RunLoop, run the current RunLoop and handle the
> callbacks, unschedule and join the thread when the download is finished.
> What is your usage pattern?
>
>
> On Aug 29, 2008, at 10:21 AM, Bertrand Landry-Hetu wrote:
>
>> I used to have many threads talking to one server using CFHTTPMessage
>> and everything was fine until I had to turn on
>> kCFStreamPropertyHTTPAttemptPersistentConnection, which turned out to
>> not be thread safe (at least from what I can see in the 10.4 source
>> code that was made public).
>>
>> Nowadays, to be really safe, I keep all my CFNetwork traffic in the
>> same background thread and I haven't had any issues since.
>>
>> 2008/8/28 Mark Thomas <email@hidden>:
>>>
>>> Hi All,
>>> Was wondering if anybody could advise on how thread safe the
>>> CFHTTPMessage
>>> / CFReadStream API's where ? (I am aware that I can use a runloop call
>>> function, but I'm working on keep the main thread to a minimum)
>>>
>>> Thanks
>>> Mark.
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Macnetworkprog mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>>
>>> This email sent to email@hidden
>>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Macnetworkprog mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _Mark
> email@hidden
>
>
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden