Re: CFHTTPMessage and thread safety
Re: CFHTTPMessage and thread safety
- Subject: Re: CFHTTPMessage and thread safety
- From: Mark Pauley <email@hidden>
- Date: Fri, 29 Aug 2008 13:13:44 -0700
Yes, this should absolutely work. If you could file a bug with a
sample tool (or app), it would help a lot.
Moreover we shouldn't be leaving sockets to the endpoint open even
when we're not in the persistent connection mode. Are you
unscheduling and releasing your CFHTTPReadStreams? What does netstat
say is happening on the desktop side? If you see a bunch of
connections sitting with no bytes in their kernel buffers (maybe
they're in the close_wait state) then that's definitely wrong.
On Aug 29, 2008, at 1:09 PM, Bertrand Landry-Hetu wrote:
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
_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