Hannes Magnusson wrote:
On Mon, Apr 26, 2010 at 16:32, mathieu.suen wrote:
Hi,
I am wondering why is the token name so incomprehensible ?
Like T_PAAMAYIM_NEKUDOTAYIM...
"Paamayim Nekudotayim would, at first, seem like a strange choice for
naming a double-colon. However, while writing
Hi
2010/3/24 Lukas Kahwe Smith :
> Yeah, lets get that clarified. Derick has stepped up and seems quite
> committed and nobody seemed to oppose him RMing the next release. In case he
> feels he needs support he can propose a co-RM, after all its important that
> the two RM's know and trust each
On 26.04.2010 23:12, Ferenc Kovacs wrote:
> You are so kind. I'm so proud of you!!
> But sticking with a real world scenario:
> you have to convert what they upload, and thats pretty random.
Yes.
And there is no way to fix it.
But that doesn't mean there MUST be any leaks at all.
Btw, there are a
On Mon, Apr 26, 2010 at 8:45 PM, Antony Dovgal wrote:
> On 26.04.2010 22:25, Ferenc Kovacs wrote:
> >
> > If you have any problems with third-party libs leaking memory not
> > accounted by Zend MM, you can always lower
> > the max_requests parameter in your config file.
> >
> > Th
On 26.04.2010 22:25, Ferenc Kovacs wrote:
>
> If you have any problems with third-party libs leaking memory not
> accounted by Zend MM, you can always lower
> the max_requests parameter in your config file.
>
> That's all. Problem solved.
>
>
> Its not the best idea. If you feed
> If you have any problems with third-party libs leaking memory not accounted
> by Zend MM, you can always lower
> the max_requests parameter in your config file.
>
> That's all. Problem solved.
>
>
Its not the best idea. If you feed imagick with random images, then your
memory leak will be pretty
On Mon, Apr 26, 2010 at 16:32, mathieu.suen wrote:
> Hi,
>
> I am wondering why is the token name so incomprehensible ?
> Like T_PAAMAYIM_NEKUDOTAYIM...
"Paamayim Nekudotayim would, at first, seem like a strange choice for
naming a double-colon. However, while writing the Zend Engine 0.5
(which p
On 26.04.2010 19:20, looyao teng wrote:
> 2. The PHP's management of memory can't give the occupied memory
> back to the system by itself.
This is simply not true.
It does cache some blocks, but usually the memory is simply free()d.
> 3.Though the idea is good,it cannot acquiret the actual state
Thanks for your continuing discussions, as the person who
gave this suggestion, I want to express my ideas.
1. The focus of this suggesting is that to free
the occupied memory in order to memory can be used
efficiently, at the same time, system have more free memory
to allocate. This has noting
On 26.04.2010 16:32, mathieu.suen wrote:
> I am wondering why is the token name so incomprehensible ?
> Like T_PAAMAYIM_NEKUDOTAYIM...
Historical reasons, easter egg, call it what you want, but it's probably
gonna stay.
http://en.wikipedia.org/wiki/Scope_resolution_operator#PHP
Cheers,
Jordi
Hi,
I am wondering why is the token name so incomprehensible ?
Like T_PAAMAYIM_NEKUDOTAYIM...
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Let's start from the beginning.
How are you going to detect how much memory a thread consumes?
no ideas
There is an old patch in the Zends PAT directory http://devzone.zend.com/content/patch/pat38.txt (it reads the /proc/pid though or
fallbacks to getrusage).
Have used this for quite a tim
Op 26-4-2010 16:05, Antony Dovgal schreef:
On 26.04.2010 18:02, Jille Timmermans wrote:
memtrack could do the usual trick; stopping the current script or whatever.
and FPM could flag the process as 'over the memory limit' and can kill it as
soon as there are no other threads running in that proc
On 26.04.2010 18:02, Jille Timmermans wrote:
> memtrack could do the usual trick; stopping the current script or whatever.
> and FPM could flag the process as 'over the memory limit' and can kill it as
> soon as there are no other threads running in that process.
There are no threads in FPM or Fa
Op 26-4-2010 13:18, Jérôme Loyet schreef:
Le 26 avril 2010 13:12, Antony Dovgal a écrit :
On 26.04.2010 14:08, Jérôme Loyet wrote:
What exactly are you going to do?
Killing a process is as easy as exit(), no interfacing is needed.
and when threads are used ? You'll kill all threads at once w
Le 26 avril 2010 13:12, Antony Dovgal a écrit :
> On 26.04.2010 14:08, Jérôme Loyet wrote:
>>> What exactly are you going to do?
>>> Killing a process is as easy as exit(), no interfacing is needed.
>>
>> and when threads are used ? You'll kill all threads at once without
>> waiting them to finish
On 26.04.2010 14:08, Jérôme Loyet wrote:
>> What exactly are you going to do?
>> Killing a process is as easy as exit(), no interfacing is needed.
>
> and when threads are used ? You'll kill all threads at once without
> waiting them to finish what they're doing at the time ?
Let's start from the
Le 26 avril 2010 12:02, Antony Dovgal a écrit :
> On 26.04.2010 13:38, Jérôme Loyet wrote:
>> I see how adding limits but how can a PECL module can do process
>> management (killing) without interfacing with the corresponding SAPI ?
>
> What exactly are you going to do?
> Killing a process is as e
On 26.04.2010 13:38, Jérôme Loyet wrote:
> I see how adding limits but how can a PECL module can do process
> management (killing) without interfacing with the corresponding SAPI ?
What exactly are you going to do?
Killing a process is as easy as exit(), no interfacing is needed.
>> That's why me
Le 26 avril 2010 10:22, Antony Dovgal a écrit :
> On 26.04.2010 12:15, Jérôme Loyet wrote:
>> 2010/4/26 Antony Dovgal :
>>> On 26.04.2010 10:58, Jérôme Loyet wrote:
Le 26 avril 2010 04:02, looyao teng a écrit :
> in linux, read the /proc/self(pid)/status, and the VmRSS(real memory
hi,
I agree with Tony. Such features should be part of memtrack or the
engine but not SAPI specific.
Cheers,
2010/4/26 Antony Dovgal :
> On 26.04.2010 12:15, Jérôme Loyet wrote:
>> 2010/4/26 Antony Dovgal :
>>> On 26.04.2010 10:58, Jérôme Loyet wrote:
Le 26 avril 2010 04:02, looyao teng a
On 26.04.2010 12:15, Jérôme Loyet wrote:
> 2010/4/26 Antony Dovgal :
>> On 26.04.2010 10:58, Jérôme Loyet wrote:
>>> Le 26 avril 2010 04:02, looyao teng a écrit :
in linux, read the /proc/self(pid)/status, and the VmRSS(real memory
usage)
or VmSize(virtual memory usage) is the th
2010/4/26 Antony Dovgal :
> On 26.04.2010 10:58, Jérôme Loyet wrote:
>> Le 26 avril 2010 04:02, looyao teng a écrit :
>>> in linux, read the /proc/self(pid)/status, and the VmRSS(real memory usage)
>>> or VmSize(virtual memory usage) is the the memory usage of the current
>>> process.
>>
>> in
On 26.04.2010 10:58, Jérôme Loyet wrote:
> Le 26 avril 2010 04:02, looyao teng a écrit :
>> in linux, read the /proc/self(pid)/status, and the VmRSS(real memory usage)
>> or VmSize(virtual memory usage) is the the memory usage of the current
>> process.
>
> in fact I was looking of a cleaner w
Hello !
in linux, read the /proc/self(pid)/status, and the VmRSS(real memory usage)
or VmSize(virtual memory usage) is the the memory usage of the current
process.
in fact I was looking of a cleaner way to do it.
Moreover, this solution is not available on OS like *BSD...
Best reg
25 matches
Mail list logo
