> From: eryk...@gmail.com
> Date: Thu, 14 Jan 2016 04:42:57 -0600
> Subject: Re: [Tutor] Question about the memory manager
> To: tutor@python.org
> CC: sjeik_ap...@hotmail.com
>
> On Thu, Jan 14, 2016 at 3:03 AM, Albert-Jan Roskam
> <sjeik_ap...@hotmail.com>
On Thu, Jan 14, 2016 at 3:03 AM, Albert-Jan Roskam
wrote:
>
> These two pages are quite nice. The author says the memory used by small
> objects is
> never returned to the OS, which may be problematic for long running processes.
The article by Evan Jones discusses a
D
> From: sjeik_ap...@hotmail.com
> To: tim.pet...@gmail.com
> Date: Wed, 13 Jan 2016 08:11:11 +
> Subject: Re: [Tutor] Question about the memory manager
> CC: tutor@python.org
>
> > From: tim.pet...@gmail.com
> > Date: Sun, 10 Jan 2016 10:54:10 -0600
> >
> To: tutor@python.org
> From: __pete...@web.de
> Date: Sun, 10 Jan 2016 18:29:06 +0100
> Subject: Re: [Tutor] Question about the memory manager
>
> Albert-Jan Roskam wrote:
>
> > Hi,
> >
> > I just found a neat trick to free up an emergency stash of
On 10/01/16 16:16, Steven D'Aprano wrote:
>> rainydayfund = [[] for x in xrange(16*1024)] # or however much you need
>> def handle_exception(e):
>> global rainydayfund
>> del rainydayfund
>> ... etc, etc ...
>
> I was going to write a scornful email about how useless this would be.
Me too.
>
If you read the comment that goes with the code snippet pasted in the
original email it makes far more sense as the author is talking
specifically about out of memory errors...
"You already got excellent answers, I just wanted to add one more tip
that's served me well over the years in a variety
On 11 January 2016 at 12:15, Alan Gauld wrote:
>
> But I think that it definitely is heavily OS dependent.
> It should work in most *nix environments the first time
> you call the function. But on second call I'd expect
> all bets to be off. And in most real-time OS's
On 11 January 2016 at 15:40, Peter Otten <__pete...@web.de> wrote:
>> I can't even work out how you trigger a MemoryError on Linux (apart
>> from just raising one). I've tried a few ways to make the system run
>> out of memory and it just borks the system rather than raise any error
>> - I can
Oscar Benjamin wrote:
> On 11 January 2016 at 12:15, Alan Gauld wrote:
>>
>> But I think that it definitely is heavily OS dependent.
>> It should work in most *nix environments the first time
>> you call the function. But on second call I'd expect
>> all bets to be
Hi,
I just found a neat trick to free up an emergency stash of memory in a funtion
that overrides sys.excepthook. The rationale is that all exceptions, including
MemoryErrors will be logged.
The code is below. My question: is that memory *guaranteed* to be freed right
after the 'del'
On Sun, Jan 10, 2016 at 11:53:22AM +, Albert-Jan Roskam wrote:
> Hi,
>
> I just found a neat trick to free up an emergency stash of memory in a
> funtion that overrides sys.excepthook.
> rainydayfund = [[] for x in xrange(16*1024)] # or however much you need
> def handle_exception(e):
>
[Albert-Jan Roskam ]
> I just found a neat trick to free up an emergency stash of memory in
> a funtion that overrides sys.excepthook. The rationale is that all
> exceptions, including MemoryErrors will be logged.
> The code is below. My question: is that memory
Albert-Jan Roskam wrote:
> Hi,
>
> I just found a neat trick to free up an emergency stash of memory in a
> funtion that overrides sys.excepthook. The rationale is that all
> exceptions, including MemoryErrors will be logged. The code is below. My
> question: is that memory *guaranteed* to be
13 matches
Mail list logo