New submission from Ferringb :
During Py_Finalize (pythonrun.c), it does the following:
1) suppress signal handling PyOs_FiniInterupts
2) clear caches
3) force gc collection; first for objects, then via wiping modules.
The problem is that for unix OSs, Modules/signal.c's PyOs_FiniInter
Ferringb added the comment:
Just noticed this patch... aside from liking the intention, the api for this is
going to grow tiresome quick since it expects the FDs to already be in place;
is there any reasons a mapping wasn't used here, specifically of
(src_fd|src_fileobj) -> target_
Ferringb added the comment:
>The only question is: do other Unix also have /proc//fd? e.g.
>FreeBSD, OpenBSD. That's especially important because FreeBSD can have
>a huge RLIMIT_NOFILE by default.
Unless the OS gives some way to optimize the process (whether inferring from
pro
Ferringb added the comment:
In #13788, I've uploaded a patch modifying closerange along the same lines as
this discussion; someone w/ appropriate rights should set dependencies as
needed.
Either way, here's a question: does anyone actually know of a unix that does
procfs, and
Changes by Ferringb :
Removed file: http://bugs.python.org/file24241/closerange-optimization.patch
___
Python tracker
<http://bugs.python.org/issue13788>
___
___
Pytho
Ferringb added the comment:
Fixed tabs/spaces...
--
Added file: http://bugs.python.org/file24242/closerange-optimization.patch
___
Python tracker
<http://bugs.python.org/issue13
New submission from Ferringb :
The current implementation of closerange essentially is a bruteforce invocation
of close for every integer in the range.
While this works, it's rather noisy for stracing, and for most invocations, is
near a thousand close invocations more than needed.
As
Ferringb added the comment:
> the test must be skipped where os.fork() isn't available (namely, under
> Windows)
Done, although I still humbly suggest telling windows to bugger off ;)
> I would do os.read(fd, 100) (or some other large value) rather than
> os.read(fd, 6),
Changes by Ferringb :
Removed file:
http://bugs.python.org/file23066/unique-seed-per-process-tempfile.patch
___
Python tracker
<http://bugs.python.org/issue12
New submission from Ferringb :
Roughly; tempfile's uniqueness is derived from a global random instance; while
there are protections for thread access, a forked child process /will/ inherit
that PRNG source, resulting in children/parent trying the same set of names.
Mostly it'
Ferringb added the comment:
Bleh; pardon, reuploading the patch. hg export aparently appends to the output
file rather than overwriting it (last patch had duplicated content in it).
--
Added file:
http://bugs.python.org/file23067/unique-seed-per-process-tempfile.patch
11 matches
Mail list logo
