Charles-Francois Natali <neolo...@free.fr> added the comment: 2011/3/3 Antoine Pitrou <rep...@bugs.python.org>: > > Antoine Pitrou <pit...@free.fr> added the comment: > >> Just to be clear, I'm not at all criticizing the current GIL >> implementation, there's been a great work done on it. >> I'm just saying that releasing and re-acquiring the GIL around fast >> syscalls is probaly not a good idea. > > If these syscalls aren't likely to yield control to another thread, then > I agree there's no point in releasing the GIL around them. > (but is it the case that they are always fast? for example, how about > dup() on a network file system? or is it indifferent?)
The initial open can take long, but once it's open, calling dup just implies copying a reference to the open file (a pointer) to the file descriptor table. No I/O is done (I tested it one a NFS mount). Now, I don't know Windows at all, but I'm pretty sure that every operating system does more or less the same thing, and that those three calls (there might be others) don't block. > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue11382> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11382> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
