libera/#commonlisp - IRC Chatlog
Search
19:34:01
etimmons
salt rock lamp: I promised you a link to my work in progress on libgit2. Sorry it took so long: <https://gitlab.common-lisp.net/etimmons/cl-libgit2>
19:34:41
etimmons
salt rock lamp: The lispified wrappers are very much in the experimentation phase, so I can't really recommend using it.
19:35:50
jcowan
The modern view seems to mean that "parallel" does mean" "at the same time", in which case let-bindings are better described as concurrent. This view goes back to at least 1968.
19:38:26
jcowan
Throwing up and catching two balls with two hands is a parallel operation. Juggling three balls with two hands is a concurrent operation.
19:56:27
pjb
Josh_2: if you get storage-condition, and know what to do about them (eg. free some memory), then catch it. Explicitely, and precisely it. But don't catch other non-error conditions that you don't know, and that other parts of the system may rely catching.
19:57:02
pjb
Josh_2: catch storage-condition with handler-bind, it makes no sense catching it with handler-caseā¦
23:50:44
semz
Is it legal to preallocate a single storage-condition for this situation and just reuse it every time?
23:51:13
White_Flame
the system should at least leave space for creating/handling out of memory conditions, I don't think it's a problem for you to do the same
23:52:18
White_Flame
however, it's not just the condition object. Any consing, including during printing, can still be problematic
23:53:38
hayley
Apparently not, the notes are just about what can signal STORAGE-CONDITION (tl/dr everything).
23:57:29
specbot
Resignaling a Condition: http://www.lispworks.com/reference/HyperSpec/Body/09_adaa.htm
23:57:33
saturn2
it should be legal to preallocate a storage-condition and then make a new one after it's been handled and there's room again
0:00:11
saturn2
maybe it doesn't matter since this rule only applies "during the dynamic extent of the signaling process"
0:02:04
saturn2
and running out of memory again while handling a storage-condition just means the world ends anyway
0:02:09
semz
Are conditions themselves guaranteed to survive the signalling process? If they don't, one could reuse the space. Doesn't deal with OOM during the OOM handler but arguably this is a major user fuckup.
0:08:04
Nilby
IIRC some lisp machines had a memory reserve for handling out of memory conditions, and also the firmware could save a restartable image if things got really bad
6:23:09
pjb
semz: good question (reuse of conditions). 1- we can signal the same condition several times. 2- most condition classes in the standard don't have slot writers (therefore in a new situation, there's no standard API to mutate it, but nothing prevents an implementation to have and do it). 3- usually, conditions are not collected, ie. if a condition was mutated, this would have no consequence, because nobody keeps references to old conditions.
6:25:00
pjb
semz: so in the spirit of the standard, it would be best if the condition was pre-allocated, but not reused. It could be allocated when the garbage collector can free enough memory for it. But it would be preferable to allocate a new one each time it's signaled.
6:25:59
pjb
while conditions are not usually collected, this is something that is perfectly conceivable: you could keep reference to old conditions in an object-oriented logging system.
6:40:49
specbot
Resignaling a Condition: http://www.lispworks.com/reference/HyperSpec/Body/09_adaa.htm
7:00:26
pjb
Alfr: thank you. Indeed. The problem is that the code that signals a condition cannot know when the handling of the condition is finished. It's definitely not when we're out of a handler-bind, but even not when we're out of a handler-case. For example, the handler could store the condition (with the situation that led to its signaling embedded in it), and process it later.
7:00:54
pjb
So indeed, conditions can be pre-allocated, but they should be used for a single situation.
7:12:11
pjb
semz: note that when a storage-condition occurs, the condition object is not the only object that needs to be allocated. We may also need to allocate some string (error message), some bignum (memory size, etc), and some other temporary object. Therefore it's probably best managed by reserving some memory zone where to allocate those objects, at the level of the memory manager.