4 ms·
To clarify a little, this patch does not eliminate the GIL it just schedules the next thread to acquire the GIL using the BFS scheduling algorithm. Also and pe
by janzer 17y ago
To clarify a little, this patch does not eliminate the GIL it just schedules the next thread to acquire the GIL using the BFS scheduling algorithm.
Also and perhaps more importantly this has not been incorporated into any version of python. It is just a patch on the bug tracker and realistically I doubt it has much chance of being accepted.
- kinghajj 17y agoIf he's fixed the bugs and gotten it to be portable (at least to POSIX), then why shouldn't it get adopted? Just look at those benchmark results! 259ms per loop instead of the next best of 1.25s. If a real app gets improvements from this, it should be a no-brainer.
- mbreese 17y agoI'd wait to see how this works with a real workload as opposed to his contrived example. It looks like it might be good, but it definitely needs to be better tested.
- sid0 17y agoGlancing at the patch, it looks like it should work on both POSIX and Win32.
- JoachimSchipper 17y agoAt least the patch as first proposed suffered from all-the-world-is-Linux (see the discussion of CLOCK_THREAD_CPUTIME_ID)...
- prewett 17y agoIt was based off a piece of the Linux kernel... I'd say it isn't so much an all-the-world-is-Linux so much as Linux is what is available.
- rbanffy 17y agoYou have to start with one platform. You then make it work on the others. If I write something that initially only runs on IRIX and then make it work on other OSs, it would be unfair to attribute it an all-the-world-is-IRIX. It just happens the guy had a Linux box to refine his idea to the point of working, unfortunately using stuff other OSs don't offer in the same way.
- jrockway 17y agoAssuming it fixes your app, instead of using "python" to run it, you just start using his version. The joys of open source.
- rbanffy 17y agoThe problem then is that you now have to maintain your own fork of Python. Again, the joys of open-source ;-)
- jrockway 17y agoThis is easier than it sounds.
- jerf 17y agoWell, it would be easier than it sounds but a bit of Googling reveals that while Python plans on moving to Mecurial, it's still in SVN. Still, git-svn can solve that problem pretty well.
- rbanffy 17y agoIf it's easy, chances are many people will participate and the fork will take on a life of its own. If not, you will have to merge back the patch from time to time. It's not a terrible thing, if the parts the patch changes don't get changed often. If they do, it could quickly turn into a nightmare
- alnayyir 17y agoI program in Python (Django) full-time. It's my job. I'm the only developer at my company who knows C. I'm sorry but mere mortals who just want to get stuff done are not going to maintain their own fork of an entire programming language. I don't know what alternative reality you've been spending your time in (academia? FSF employee?) but it's simply not going to occur unless someone else takes up the burden and makes regular public releases. Notice that usage of CK patches by Linux users evaporated as soon as he went on software sabbatical. Open source is not driven by crowd sourcing or collective effort, it's driven by a small number of heroes willing to devote time in order to benefit everyone else.
- hartror 17y agoWow I was excited and confused for a second, I thought the impossible had been done! That's fine that it hasn't I am happy with Twisted Spread for multi-process RPC needs.