Re: Data downloading performance
Re: Data downloading performance
- Subject: Re: Data downloading performance
- From: Rafael Cerioli <email@hidden>
- Date: Sat, 17 Jul 2010 16:27:42 -0400
Le 17 juil. 2010 à 12:19, Ken Thomases a écrit :
> On Jul 17, 2010, at 10:38 AM, Rafael Cerioli wrote:
>
>> Just out of curiosity, if there is communication between threads, even with runloops, there must be a lock at some point ? To schedule something in the main thread's runloop, you must lock the runloop don't you ?
>
> No. There are lockless data structures, there are communication channels such as pipes, sockets, Mach ports, etc. There are a variety of techniques for communicating between threads that don't require locks.
>
> It's not even clear what you mean by "lock the runloop", anyway. A runloop is typically idle, blocked in a system call such as mach_msg(). If you wanted to "lock" it, you'd have to wake it, which would entail communicating with it, which means you've already achieved what you contend can only be achieved by locking it.
>
Ok, I think It's clearer now, thank you. My question made indeed no sense, but had I figured that out, I wouldn't have needed to ask it.
>
>> But still, why would I bother running my NSURLConnection on the main thread, knowing that my parsing will have to be done in a background thread and I would have to deal with synchronization matter ? Why not just doing all the stuff in an NSOperation or a "detachedNewThreadSelector" ? (I mean, if you take apart the bugs reported, which apparently does not occur on iOS, not anymore in any case)
>>
>> I'm looking for a technical explanation there, not just a "don't do that" because of general opinion, I don't like much "common beliefs" if they aren't justified by some technical proofs (again if you take apart the bug thing - assume this works with no bugs, is it just more or less efficient ?).
>
> Sorry to disappoint, but there's no hard technical proof. You asked for advice, you get advice -- opinion earned through hard-won experience. Nobody can prove their experience to you.
>
> Many of us have lots of experience working with threads. In the early going we made a lot of mistakes and learned expensive lessons.
>
> Many of us have also dealt on this list and in other forums with programmers new to threads and have seen them be naive about them, seen them refuse good advice, seen them get into trouble and had them come running back asking for help in how to get themselves out of the mess they've gotten themselves into.
>
> Frankly, your questions so far, such as the one I quote at the top, reflect such naivete. You have intuitions and assumptions about how threading works, or how it might simplify your code, but they're not particularly accurate or informed. It is certainly _possible_ that delving into threading is a solution to a given problem, but it's more likely to burn an inexperienced programmer than to help.
>
> Regards,
> Ken
Ok, ok busted : I'm not much experienced ! That's precisely why I was writing to that list in the first place : trying to get knowledge more concrete than my intuitions, I thought that was the point.
If I understood you correctly, as an inexperienced programmer I should avoid threading as much as possible, and I should do so because experienced people told me to without giving an explanation (except that "you'll get into trouble").
Or I do not, and I might learn some interesting yet expensive lessons about threading.
Is there no reason understandable by young programmers about why we should avoid threading and NSURLConnection ?
Or at least a good piece of documentation ? (would you say Threading Programming Guide is a good one ? )
Thank you,
Rafael
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden