On Fri, 1 Feb 2013 15:25:27 -0800
"Gregory P. Smith" wrote:
> On Fri, Feb 1, 2013 at 7:22 AM, Antoine Pitrou wrote:
>
> > Le Fri, 1 Feb 2013 15:18:39 +0100,
> > "Amaury Forgeot d'Arc" a écrit :
> > > 2013/2/1 Charles-François Natali
> > >
> > > > >> dup2(oldfd, newfd) closes oldfd.
> > > > >
>
On Fri, Feb 1, 2013 at 7:22 AM, Antoine Pitrou wrote:
> Le Fri, 1 Feb 2013 15:18:39 +0100,
> "Amaury Forgeot d'Arc" a écrit :
> > 2013/2/1 Charles-François Natali
> >
> > > >> dup2(oldfd, newfd) closes oldfd.
> > > >
> > > > No, it doesn't close oldfd.
> > > >
> > > > It may close newfd if it w
Amaury Forgeot d'Arc wrote:
One reasonable heuristic is to check the man page: if the syscall can
return EINTR, then the GIL should be released.
Hmmm, curious. According to the MacOSX man pages, both
dup() and dup2() can return EINTR, but pipe() and
socketpair() can't.
I'm particularly
Charles-François Natali wrote:
Anyway, only dup2() should probably release the GIL.
Depending on how your kernel is implemented, both pipe()
and socketpair() could create file system entries, and
therefore could block, although probably only for a
very short time.
--
Greg
_
ACTIVITY SUMMARY (2013-01-25 - 2013-02-01)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3848 (+11)
closed 25028 (+57)
total 28876 (+68)
Open issues wit
Le Fri, 1 Feb 2013 15:18:39 +0100,
"Amaury Forgeot d'Arc" a écrit :
> 2013/2/1 Charles-François Natali
>
> > >> dup2(oldfd, newfd) closes oldfd.
> > >
> > > No, it doesn't close oldfd.
> > >
> > > It may close newfd if it was already open.
> >
> > (I guess that's what he meant).
> >
> > Anyway,
2013/2/1 Charles-François Natali
> >> dup2(oldfd, newfd) closes oldfd.
> >
> > No, it doesn't close oldfd.
> >
> > It may close newfd if it was already open.
>
> (I guess that's what he meant).
>
> Anyway, only dup2() should probably release the GIL.
>
> One reasonable heuristic is to check the m
Bugs #17098 and #17099 filed.
On Fri, Feb 1, 2013 at 1:56 AM, Thomas Heller wrote:
> Am 01.02.2013 01:42, schrieb Nick Coghlan:
>
> Yep, looks like a bug in the bootstrapping, failing to set __loader__
>> properly.
>>
>
> It also has the effect that reload does not work:
>
>
> Type "help", "co
>> dup2(oldfd, newfd) closes oldfd.
>
> No, it doesn't close oldfd.
>
> It may close newfd if it was already open.
(I guess that's what he meant).
Anyway, only dup2() should probably release the GIL.
One reasonable heuristic is to check the man page: if the syscall can
return EINTR, then the GIL
> dup2(oldfd, newfd) closes oldfd.
No, it doesn't close oldfd.
It may close newfd if it was already open.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
On 01/02/2013 1:44am, Guido van Rossum wrote:
I'm guessing those system calls are just implemented by the kernel and
cannot block for I/O, so it was deemed unnecessary to release the GIL
around them. I don't mind changing that though, you can never know
what happens when you make a system call.
Hi All,
We create our customised manager which will fork child process with
baseManager. Because we registered SIGCHLD to reap the zombie for manager, we
found this causes baseManager raise RemoteError when called twice.(Test script
attached.)
After look at baseManager.py we found recv() in h
12 matches
Mail list logo
