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
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.
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
>> 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
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
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
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,
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
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
_
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
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
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.
> > > > >
>
12 matches
Mail list logo
