Antoine Pitrou wrote:
>Now please read my message again. The OS buffers are *not* flushed according
>to POSIX.
POSIX says open *streams* might not be flushed. POSIX streams are C
FILE * streams and generally aren't regarded as being part of the OS.
When you call os._exit() in a Python program
On Fri, Mar 1, 2013 at 5:51 PM, Antoine Pitrou wrote:
> Dave Angel davea.name> writes:
> >
> > Note he didn't say the python buffers would be flushed. It's the OS
> > buffers that are flushed.
>
> Now please read my message again. The OS buffers are *not* flushed
> according
> to POSIX.
>
I ha
Dave Angel davea.name> writes:
>
> Note he didn't say the python buffers would be flushed. It's the OS
> buffers that are flushed.
Now please read my message again. The OS buffers are *not* flushed according
to POSIX.
--
http://mail.python.org/mailman/listinfo/python-list
On 03/01/2013 02:10 PM, Antoine Pitrou wrote:
Grant Edwards invalid.invalid> writes:
All open files (including sockets, pipes, serial ports, etc) will be
flushed (from an OS standpoint) and closed.
According to POSIX, no, open files will not be flushed:
“The _Exit() and _exit() functions s
Grant Edwards invalid.invalid> writes:
>
> > I assume that the memory used by the Python process will be reclaimed
> > by the operating system, but other resources such as opened files may
> > not be.
>
> All open files (including sockets, pipes, serial ports, etc) will be
> flushed (from an OS
Steven D'Aprano pearwood.info> writes:
>
> I just quit an interactive session using Python 2.7 on Linux. It took in
> excess of twelve minutes to exit, with the load average going well past 9
> for much of that time.
>
> I think the reason it took so long was that Python was garbage-collecting
On 2013-02-28, Steven D'Aprano wrote:
> I know there is a function os._exit which effectively kills the
> Python interpreter dead immediately, without doing any cleanup. What
> are the consequences of doing this?
You loose any data you haven't saved to disk.
> I assume that the memory used by t
On Thu, Feb 28, 2013 at 12:06 PM, Chris Angelico wrote:
> Is it any different if you create a deliberate reference loop and then
> stuff it into some module somewhere? That would force it to be kept
> until interpreter shutdown, and then a cyclic garbage collection after
> that, which quite probab
On Thu, Feb 28, 2013 at 12:31 PM, Devin Jeanpierre
wrote:
> On Thu, Feb 28, 2013 at 12:06 PM, Chris Angelico wrote:
>> Is it any different if you create a deliberate reference loop and then
>> stuff it into some module somewhere? That would force it to be kept
>> until interpreter shutdown, and t
On Fri, Mar 1, 2013 at 4:31 AM, Devin Jeanpierre wrote:
> On Thu, Feb 28, 2013 at 12:06 PM, Chris Angelico wrote:
>> Is it any different if you create a deliberate reference loop and then
>> stuff it into some module somewhere? That would force it to be kept
>> until interpreter shutdown, and the
On 2013-02-28, Steven D'Aprano wrote:
> Can anyone explain why this was so painfully slow, and what (if
> anything) I can do to avoid it in the future?
I think your explanation makes sense. Maybe the nested nature of
the strings was causing it to churn looking for circular
references?
Disabling
I just quit an interactive session using Python 2.7 on Linux. It took in
excess of twelve minutes to exit, with the load average going well past 9
for much of that time.
I think the reason it took so long was that Python was garbage-collecting
a giant dict with 10 million entries, each one cont
12 matches
Mail list logo
