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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
