I don't think it's regional. I'm in Sweden and if I visit the Flash install page with IE I get Chrome as pre-selected and if I visit with Firefox I get the McAfee add-on. (And when I'm using Linux, as usual, there are no extra applications installed.)
I don't think you should have to do neither convincing the IT department nor refunding them. One part of their organization chose to order the Java applet solution from you and another part of their organization chose to uninstall Java. The fact that they ordered a solution that they can't use isn't your fault. If they want you to use your time to work out a solution with the IT department how the applet can be used securely I think they need to pay you for that time (charge per hour for that, if the IT department is stubborn they have to pay more).
I noticed I got the Swedish URL. I tried to find an international or English URL, but I couldn't find it, I hope you get English text anyway.
When I just visit that page it suggests that I download version 10.3.183.10, but if I choose to download for another OS or browser version 11 is available for Windows, Mac OS X and Linux. 64 bit version for Linux is finally stable.
In the section "Be precise and informative about your problem" of the article there is a link to Simon Tatham's (PuTTY author) "How to Report Bugs Effectively": http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
I've seen several open source projects link to that document as well, so it might be what you are looking for.
> The note is really about the best way to specify a range/sequence of integers, not why we start from 0 as an index.
Dijkstra deals with what index start with as well, but it comes out as a consequence of which bounds to choose for a range, so it's rather short.
From the article:
When dealing with a sequence of length N, the elements of which we wish to distinguish by subscript, the next vexing question is what subscript value to assign to its starting element. Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i < N+1; starting with 0, however, gives the nicer range 0 ≤ i < N.
He's not saying that. He's saying that the GIL isn't a limitation to certain kinds of application, the kinds that Python usually is used for. The kinds of applications where the GIL would be a limitation, Python also has another limitation: slow performance, and performance is usually the reason to run things in parallel.
With PyPy the performance will get better, and they also have a GC, so that hinder is removed. I don't really know if PyPy has a GIL, I would guess that they don't.
"With PyPy the performance will get better, and they also have a GC, so that hinder is removed. I don't really know if PyPy has a GIL, I would guess that they don't."
Ok, the PyPy FAQ says: "Yes, PyPy has a GIL. Removing the GIL is very hard. The first problem is that our garbage collectors are not re-entrant."
Is it really necessary for the GC to be re-entrant to run the interpreter in parallel? Couldn't you have the interpreter running in parallel and then when there is a need to run the GC you have a global GC lock that prevents all threads from running - a stop the world GC. The application runs for a longer time than the GC, right? So it would be a win and a step in the right direction? I believe the early Java mark and sweep GC was like that, and then later Sun developed several different kinds of concurrent and parallel GCs.
> Official PyPy Status Blog
Oh I read that every time they write something. :) But I started reading it in late 2010 and I haven't gone back to the archives, I guess it's time to do that. Thanks for the links.
> I dont' understand. Isn't this going to happen if you have multiple threads running even if the GIL is blocking them from running?
I don't think it would. If there is a GIL (Global Interpreter Lock) only one thread of the process can be scheduled to run at any time. As the poster (Sturla) says, Python threads are native OS threads so they should be scheduled by the OS kernel (right?). A good scheduler would use affinity scheduling and schedule all threads of the Python program on the same processor/core every time to get benefits from cached data and code. I believe modern kernels (Linux, MacOS, Solaris, probably Windows as well) use this kind of affinity scheduling, so if we're lucky the Python process gets scheduled on the same processor every time and there will be no need any cache synchronization.
> I'm not a hardware expert, but I'm not sure how constant locking would prevent cache synchronization just because they weren't truly running in parallel.
I'm not sure if you misunderstood the mail. The constant locking would only be used if they were running in parallel.
Anyway, if you have a GIL you don't need that kind of locking described in the mail. You only need to do explicit locking on shared data structures when you read or update the contents of those data structures. If you have reference counting, threads that run in parallel and no GIL you would have to lock even if you are just assigning a reference to such a data structure to a new variable. If you have a GIL you are certain that only one thread at a time are updating the reference count. That is indeed what the GIL is, one coarse lock for all data (and the interpreter) instead of fine grained locks for every data structure.
(I don't know Python very well, I just answer from general knowledge of computer architecture and language implementation. But I've read about the Python GIL several times, since it's the most discussed GIL of any language.)
I don't think there's anything to prevent more than one thread from being scheduled at any time. They just block when trying to run concurrently because of the GIL.
>I'm not sure if you misunderstood the mail. The constant locking would only be used if they were running in parallel.
No, I'm saying that the GIL is constant locking. You still have two threads being run concurrently on (possibly) two separate cores accessing the same cache lines. They just cannot actually run in parallel. I have no idea how the GIL time slices between the two threads, so what i'm saying is completely possible.
However, below my original post meastham correctly pointed out the GIL does prevent cache thrashing where updates to shared memory might go back and fourth multiple times unnecessarily. So it's not as bad as I was imagining.
Yes, you are right that the OS can schedule two Python threads to run at the same time, it's just that one of them will only run a few instructions and then block, just not any Python instructions. I hadn't really thought that through thoroughly, thanks for pointing it out.
Ah, I see now what you meant with constant locking. I interpreted your words as "constant" as in happening all the time as would be the case with fine grained locks instead of one long-lasting, global lock.
