|
|
Re: It isn't Easy to Remove the GIL
|
Posted: Sep 16, 2007 5:31 PM
|
|
Bruce, I'm a bit disappointed about you sinking to such a low with your response. A personal attack of that form - nicely veiled as it was - clearly was not necessary. Especially, if you could have just assumed a little less and actually bothered to read what I wrote.
Oh well, I'll try to answer anyway.
> This is one of the characteristic comments made by people
> who trivialize the complexity of threading. And it's an
> excellent example: the Python API is indeed one of the
> simpler threading APIs, but to say it is "instantly
> understood" by people coming from C/C++/Java is completely
> wrong. They *think* they understand it, and only later
> discover some very important things about it. Like the
> GIL, and like the fact that it won't actually use more
> than one CPU.
Yeah, and why do I have to reiterate to you of all people that the GIL is something cPython specific, while the threading API in itself is completely independent of that? I thought we went over this many times? So, when I talk about using the API, I obviously talk about - you know - writing a program, creating threads, communicating between threads, and so forth. Nothing about the GIL.
You are absolutely right, you only learn later that the GIL actually prevents the threading in cPython to be useful in some cases, but that certainly didn't prevent me from understanding how to use the API. Maybe not even all the functions it offers, but certainly enough to get started. After all, the same threading API in Jython works just fine.
So, I have no idea what you are on about when you throw the GIL and the threading API into the same sentence.
> If someone uses "instantly understand" and
> "threading" in the same sentence, my brain rewrites that
> sentence to say "doesn't really understand threading."
Oh please! That is your problem. You assume too much, obviously. I didn't think of you that way, which is why I'm so disappointed in your post.
> > I have worked on multi-threaded systems of
> > varying levels of complexity and it is very much
> possible
> > to get them to work correctly. I never understood why
> some
> > people have such an aversion against threads. In many
> > cases, threads are a very natural way of expressing
> > program logic. And unless your data structures are
> madly
> > complex you should be able to get the locking right as
> > well. It's definitely possible, and I simply don't buy
> the
> > 'threads are wrong/evil/bad argument at all'.
>
> If you really understood how complex it is to write a
> correct threaded program, you would be concerned, not
> about yourself (because you are clearly one of the
> brilliant few to whom threading is transparently obvious),
Yes, yes, here we go. The usual lame old approach to beat another person's argument to death. Nice one, Bruce. And after that whatever I say is going to be disqualified from the start, right? Really lame.
If you would have read what I wrote, you would have seen this: "In many cases, threads are a very natural way of expressing program logic." I wrote: In many (!) cases. Not all!
I also said that the difficulty of 'getting threading right' will depend on the complexity of the data structures you are dealing with. You didn't see this either? Apparently not. You just felt like going on a rant like this.
> but about all the other programmers who aren't as smart as
> you are.
Same old, same old.
> Such brilliant people exist; they look at something and
> the answer seems obvious and they don't understand why it
> isn't obvious to everyone else. But (1) those aren't most
> programmers and (2) I generally find that this kind of
> overconfidence eventually produces catastrophic results.
Yes, well, good for them if they are so smart. It's not always obvious for me at all. And sure, baseless overconfidence can produce catastrophic results.
> And I keep running into people who appear to be very smart
> but don't seem to agree with you. Like Brian Goetz, who
> varies between saying that threads are "extremely
> difficult" to "impossible" to get right.
As a general case, I can believe that. But making threads out to be evil because of that is not right either. As I said (do I have to repeat it?): There are some problems for which they work very well. I won't use them for everything, but I have come across many issues where they just worked and worked well.
Hey, maybe I have a completely bizarre and odd career path which led me to have those experiences, but frankly, I don't think so. Maybe the smart people I was lucky enough to work with where all just totally overconfident or those few exceptions you talk about, but somehow, I don't think so.
> Not that this will have any effect, since you've already
> decided that threads are trivial to understand and to
> program correctly.
[ the usual lame rhetoric designed to discredit whatever else I could say ahead of time... ]
> But try to understand in this moment
> that the vast majority of programmers may not have your
> insights. And also that you may have one or two "aha"
> moments in the future where you realize that you didn't
> really understand threads before.
Oh come on, I didn't just come crawling out from under a rock, you know? Don't you think I have had moments where it was tough to get the threading right? Of course I did! That's why I said (over and over again): Threads are a natural fit for many problems, but 'many' does not mean 'all' as you may faintly recall. If you stick to the problems for which they are a fit then you won't have all those 'terrible, evil' problems you are going on about here.
Juergen
|
|
Previous Topic
