Re: allocation within critical sections

[Mike Gran]

> From: Andy Wingo <address@hidden>
 >>  As an aside, I can get a similar sort of deadlock during garbage
>>  collection of SMOBs if my smob_free function calls a scheme function.
>>  But the manual does note that you should not call any functions in 
>>  SMOB GC finalizers, so that wouldn't happen if I actually followed the
>>  instructions.
> 
> Any Scheme function?  With Guile 2.0?  It should be possible to call
> arbitrary code from finalizers, if we call finalizers from a separate
> thread.

Happens with any scheme function called in a SMOB's finalizer, with Guile 2.0,
in a memory constrained situation.
 
For example, Guile-ncurses has a SMOB finalizer that calls a guardian previously
created with 'make-guardian'.  This is in the <form> SMOB.
 
Here's the order of operations

- GC_invoke_finalizers calls the <form> SMOB's free function 'gc_form_free'

- my SMOB finalizer gc_form_free calls a guardian procedure with
scm_call_0 remove the guardian

- That kicks off a new scm_c_vm_run then calls scm_i_smob_apply_trampoline
 
- there is some mutex in the trampoline process

- A new trampoline causes a memory allocation with scm_hash_fn_create_handle_x

- Since memory is low, it calls GC_invoke_finalizers

- This ends up making a call to my finalizer gc_form_free.  (Don't know if this
is a recursive call to my SMOB finalizer or if it is a call to a different
<form>'s SMOB finalizer, since I have many forms)
 
- the gc_form_free calls a guardian with scm_call_0
 
- which kicks off a new scm_c_v_run

- which eventually gets you to scm_i_smob_apply_trampoline again

- which leads to a recursive mutex lock in scm_i_smob_apply_trampoline
 
-Mike