On Wed, 7 Jul 2010, Andrew Brunner wrote:
Well... I think CGI gateway is a good way. If the real app (FCGI) have
troubles, I can change the URL that the CGI (gateway) uses to call the
real app and to point to another app (in other server, e.g.). What do
you think about it?
I think it would b
In our previous episode, Andrew Brunner said:
> > Well... I think CGI gateway is a good way. If the real app (FCGI) have
> > troubles, I can change the URL that the CGI (gateway) uses to call the
> > real app and to point to another app (in other server, e.g.). What do
> > you think about it?
>
>
On 7 July 2010 15:09, Graeme Geldenhuys wrote:
> On 7 July 2010 15:44, Andrew Brunner wrote:
>>
>> As far as *HUGE* problem. Having to restart my server would be huge..
>> Especially in high scale, high available production environments.
>
> You don't have to restart the server (hardware), only t
On Wed, Jul 7, 2010 at 12:37 PM, José Mejuto wrote:
> Hello FPC-Pascal,
>
> Wednesday, July 7, 2010, 4:49:03 PM, you wrote:
>
> MD> Exactly.
> MD> I just wonder how you do in web apps that are not CGI. As I said
> MD> earlier in an email here:
> MD> http://lists.freepascal.org/lists/fpc-pascal/201
Hello FPC-Pascal,
Wednesday, July 7, 2010, 4:49:03 PM, you wrote:
MD> Exactly.
MD> I just wonder how you do in web apps that are not CGI. As I said
MD> earlier in an email here:
MD> http://lists.freepascal.org/lists/fpc-pascal/2010-July/025902.html
MD> ...but I guess that is to be reviewed, perha
On Wed, Jul 7, 2010 at 11:50 AM, Andrew Brunner
wrote:
>> Well... I think CGI gateway is a good way. If the real app (FCGI) have
>> troubles, I can change the URL that the CGI (gateway) uses to call the
>> real app and to point to another app (in other server, e.g.). What do
>> you think about it?
> Well... I think CGI gateway is a good way. If the real app (FCGI) have
> troubles, I can change the URL that the CGI (gateway) uses to call the
> real app and to point to another app (in other server, e.g.). What do
> you think about it?
I think it would be worth discussing what can be done or a
On Wed, Jul 7, 2010 at 11:35 AM, José Mejuto wrote:
> Hello FPC-Pascal,
>
> Wednesday, July 7, 2010, 3:48:13 PM, you wrote:
>
> AB> Martin, I didn't get to the end of your email because I find that
> AB> first major part - part and parcel of why Delphi failed as a language.
> AB> It became unviab
On Wed, Jul 7, 2010 at 10:44 AM, Andrew Brunner
wrote:
>
> Grame, no more caveats. If Unmount had memory that needed to be
> released then the same methodology stands. Disk1.Unmount was placed
> there to prove a point. That w/o handling Obj2.Free would never be
> called in context (the outstand
On Wed, Jul 7, 2010 at 10:28 AM, Martin wrote:
> On 07/07/2010 14:14, Marcos Douglas wrote:
>>
>> Here we have a big problem if the program is a web app using FastCGI.
>> In this case, what we do?
>>
>
> Write as much info as you have to the servers log file => so you can fix the
> app.
> Return a
Hello FPC-Pascal,
Wednesday, July 7, 2010, 3:48:13 PM, you wrote:
AB> Martin, I didn't get to the end of your email because I find that
AB> first major part - part and parcel of why Delphi failed as a language.
AB> It became unviable because exception handling and blow-outs. Which
AB> in turn we
On 7 July 2010 15:44, Andrew Brunner wrote:
>
> As far as *HUGE* problem. Having to restart my server would be huge..
> Especially in high scale, high available production environments.
You don't have to restart the server (hardware), only the application
or service (app server software). As in a
On Wed, Jul 7, 2010 at 8:34 AM, Martin wrote:
> Had you only read to the end of my mail. You are deliberately ignoring
> part of what I wrote and the blame me for the remainder being incomplete?
>
> I clearly stated that there are cases where "free" can raise a valid
> exception, and that the
On Wed, Jul 7, 2010 at 8:37 AM, Graeme Geldenhuys
wrote:
>> procedure TObj1.Free;
>> begin
>> Try
>> Disk1.Unmount;
>> Except
>> On E:Exception do begin
>> // Some case stuff here
>> end;
>> end;
>> Inherited Destroy;
>> end;
>>
>
> With the exception of a possible memory leak
On 7 July 2010 15:25, Andrew Brunner wrote:
>
> procedure TObj1.Free;
> begin
> Disk1.Unmount; <<< The disk object is missing now b/c a network failure;
> Inherited Destroy;
> end;
>
> procedure TObj1.Free;
> begin
> Try
> Disk1.Unmount;
> Except
> On E:Exception do begin
> // Some
On 07/07/2010 14:25, Andrew Brunner wrote:
On Wed, Jul 7, 2010 at 8:05 AM, Martin wrote:
if " obj1.free; " crashes, then yes obj2 is not going to be released. But as
explained in this and my last mail: It should not be attempted to be
released.
Martin, I can't disagree more. I find
On 07/07/2010 14:14, Marcos Douglas wrote:
On Wed, Jul 7, 2010 at 9:54 AM, Martin wrote:
[...snip...]
With an exception like this, the rule is: Do as little as you can.
Everything you do can make it worse. Call a function that relies on as
little data as possible, and tries to simple save
On Wed, Jul 7, 2010 at 10:05 AM, Martin wrote:
> On 07/07/2010 13:54, Martin wrote:
>>
>> On 07/07/2010 13:30, Andrew Brunner wrote:
>>>
>>> Ok. I think I understand the discrepancy in our reasoning. The issue
>>> is when exceptions are raised during Obj.Free. I think it would help
>
>
>>
On Wed, Jul 7, 2010 at 8:05 AM, Martin wrote:
>
> if " obj1.free; " crashes, then yes obj2 is not going to be released. But as
> explained in this and my last mail: It should not be attempted to be
> released.
>
Martin, I can't disagree more. I find it completely ludicrous that if
obj1.free rais
On Wed, Jul 7, 2010 at 9:54 AM, Martin wrote:
>
> [...snip...]
>
> With an exception like this, the rule is: Do as little as you can.
> Everything you do can make it worse. Call a function that relies on as
> little data as possible, and tries to simple save all user-data to an
> emergency file. T
On 07/07/2010 13:54, Martin wrote:
On 07/07/2010 13:30, Andrew Brunner wrote:
Ok. I think I understand the discrepancy in our reasoning. The issue
is when exceptions are raised during Obj.Free. I think it would help
UninitializedPointerToRandomAddress := SomeValue;
You may have change
On 07/07/2010 13:30, Andrew Brunner wrote:
On Wed, Jul 7, 2010 at 2:09 AM, Graeme Geldenhuys
wrote:
Op 2010-07-07 03:32, Martin het geskryf:
And in the 2nd case, mem leaks are no worry => the app is going to be
closed, mem will be freed by the OS.
[...snip...]
The whole memory man
On Wed, Jul 7, 2010 at 9:30 AM, Andrew Brunner
wrote:
> Ok. I think I understand the discrepancy in our reasoning. The issue
> is when exceptions are raised during Obj.Free. I think it would help
> if you would assume that all exceptions raised in Obj.Free were
> handled - since my assertion is
On Wed, Jul 7, 2010 at 2:09 AM, Graeme Geldenhuys
wrote:
> Op 2010-07-07 03:32, Martin het geskryf:
>>
>> And in the 2nd case, mem leaks are no worry => the app is going to be
>> closed, mem will be freed by the OS.
>>[...snip...]
>>
>> The whole memory management could be corrupted. Trying to fre
Op 2010-07-07 05:25, Andrew Brunner het geskryf:
> So just make sure the Destroy methods free what they are supposed to free.
What if that was the cause of the exception in the first place. :-)
eg: Exception occurs in the destructor before all resource could be freed.
Regards,
- Graeme -
--
Op 2010-07-07 03:32, Martin het geskryf:
>
> And in the 2nd case, mem leaks are no worry => the app is going to be
> closed, mem will be freed by the OS.
>[...snip...]
>
> The whole memory management could be corrupted. Trying to free
> memory could just cause more and more exceptions.
That
Op 2010-07-07 00:14, Andrew Brunner het geskryf:
>
> No, if the nesting is done properly you could guarantee that Obj2.Free
> would be called even if Obj1.Free failed with some exception.
No matter how many nested try..except or try..finally blocks you have, if
you are trying to free the instance
27 matches
Mail list logo
