This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Guile and alarm(2)


> The reason i'm asking this is that in Apache, one can set hard
> timeouts, which work by calling alarm(2), and aborting all
> processing. I'm sure that at least in those areas who are usually
> secured by SCM_DEFER_INTS / SCM_ALLOW_INTS, such an interrupt
> (without resumeing the original processing) would cause alot of
> trouble. Right?

My understanding is yes because you may have malloced some memory
and are using it for a local buffer, intending to free it again
soon. The guile docs say that in this situation you must protect
against interrupts in order to ensure that the free gets called.
I believe that SCM_DEFER_INTS / SCM_ALLOW_INTS protect against
alarm interrupts too (I could be completely wrong here).

> If so, how can i "protect" those functions, if at all? I have
> similar functions, ap_block_alarms() / ap_unblock_alarms(), which
> i could call, but do i really have to wrap every scm_* and gh_*
> call with those? I hope not :)

Well you can set a flag somewhere and make sure your alarm interrupt
returns. This won't guarantee an escape from errant code but from
normal code that is just away too long it can see the flag and bail
out. I guess it depends on your application. Interrupts with
longjumps in them are always hairy things in my opinion and I don't
see the rationale for providing complex mechanisms to protect a
program from itself (simple mechanisms, yes)

	- Tel



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]