chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Need help to understand C_mutate better.


From: Felix
Subject: Re: [Chicken-hackers] Need help to understand C_mutate better.
Date: Tue, 25 Oct 2011 09:57:24 +0200 (CEST)

> Couldn't either the signal handler return to gc, or - my preferred
> alternative - the minor gc run prior to the signal handler?
> Would make chicken robust to the case at hand.

This sounds possible, but it will trigger a collection even in cases
where it is not needed, that is, when C_reclaim was entered due to an
interrupt.

> 
> Also keeping the size of the mutation_stack down in reasonable
> bonds would IMHO make chicken better.  (More conservative wrt.
> resources.)

Some limit might be appropriate, yes.

> 
> When circumstances put too much stress on chicken, then it *can*
> run havoc.  If there where no escape, that would be a design issue.
> 

True.

> Fortunately escape is: run (gc) in signal handlers.
> That way it's transformed into a usability issue.

The signal handler will trigger a GC anyway, when it executes
normally. Remember that the signal handler does not run in any
particular "mode" - it is normal Scheme code that, once finished, will
continue at the point when the signal arrived. 

>>What rate of signals/interrupts would you expect for a heavily loaded
>>instance of your application? 
> 
> My prog works quite well under normal circumstances, and shows
> no problems at all under rscheme.  It then runs in about 70M RAM
> and CPU like 0-5%.
> 
> There are usually 50-100 subprocesses doing ssl connections.
> (Mostly standby) And there is this sqlite3 database.
> 
> Once upon a time the database is refreshed from disk content.
> Thats a background job.
> 
> Upon startup or when the laptop comes back from sleep,
> it might find out the database needs refresh.
> Chicken will read the disk file by file and talk to the sqlite3
> database
> (other pthread).
> 
> At the same time those 50-100 connection are reattempt.  Several of
> those
> will fail for sure.  Thus we'll see up to retry-times many
> subprocesses
> die off within short time.
> 
> This is sometimes enough.  (roughly 50%+/-20%)

Ok, interesting - thanks for the information.


cheers,
felix



reply via email to

[Prev in Thread] Current Thread [Next in Thread]