libera/#lisp - IRC Chatlog
Search
14:53:15
jackdaniel
there is there is a storage-condition (that is a serious-condition, but not a subclass of error)
15:01:48
jackdaniel
serious conditions are important enough that the program will refuse running until they are resolved (either with a debugger or with an appropriate handler)
15:03:32
jackdaniel
I'm not sure what do you mean by usual, but an example would be releasing some resources and invoking the garbage collector
15:03:43
amazigh
on a related subject, there is also the problem of back pressure that relates to how much cpu or i/o throughput there is available.
15:05:48
amazigh
For more than 15 years, I considered that hardware limits are oblivious; but now that I try to think about it... it is far from easy.
19:46:08
moon-child
amazigh: be careful: extant implementations do not seem to handle storage-conditions well
19:59:31
moon-child
I mean if a storage condition is signalled, insufficient memory is kept around for you to do something about it
20:00:30
jackdaniel
I can't tell for other implementations, but ecl reserves just enough storage to handle it if you are not going beyond a few kb of consing in the handler routine (i.e it reserves some space for that)
20:14:22
pdietz
amazigh: if I go to the quicklisp dist software directory and grep -r literate\ programming, I get several hits.
22:55:36
pjb
amazigh: the way to handle storage-condition is to free some storage, to be able to continue, or to cancel the current memory allocation.
22:56:27
pjb
amazigh: eg. an application could have caches that can be flushed. Or it could save to disk some unused data (open documents). etc.
22:56:51
pjb
amazigh: the problem of course, is to be able to do that without requiring more memory ;-)
1:07:24
moon-child
pjb: in principle, it would be nice to be able to do that without application interaction