[Caml-list] OCaml signal handlers (Sys.signal) and C code

[Caml-list] OCaml signal handlers (Sys.signal) and C code

[Stefano Zacchiroli]

I've noticed that a callback registered using Sys.signal function for
the Sys.sigalrm signal isn't called while executing external C code.

The execution is delayed until the C code execution is over.

Is there any way to avoid this behaviour? (Actually the only solution I
see is to modify the C code so that handler is registered there, but I'm
working with an external library which is not under my own control)

Is this an intended behaviour or a bug?

TIA,
Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml signal handlers (Sys.signal) and C code

[Xavier Leroy]

> I've noticed that a callback registered using Sys.signal function for
> the Sys.sigalrm signal isn't called while executing external C code.
> 
> The execution is delayed until the C code execution is over.
> 
> Is there any way to avoid this behaviour? (Actually the only solution I
> see is to modify the C code so that handler is registered there, but I'm
> working with an external library which is not under my own control)
> 
> Is this an intended behaviour or a bug?

Very much intended behavior.  OCaml signal handlers can execute
arbitrary Caml code, including heap allocations and garbage
collections.  If they could be invoked at any time, e.g. in the middle
of a garbage collection, disaster would ensue.

However, there is one workaround for long-running pieces of C code
that do not access the Caml heap: in the Caml/C stub code, wrap the
call to the C function as follows:

        enter_blocking_section();
        /* call C functions */
        leave_blocking_section();

In the "blocking section" that is bracketed by the calls to
enter_blocking_section() and leave_blocking_section(), signals will be
honored immediately.  However, the C code executed inside the blocking
section *must not* heap-allocate nor access the Caml heap in any way.
In practice, this means that all conversions between Caml and C data
structures must be done outside the blocking section:

        /* extract arguments from Caml data, copying them to stack-allocated
           blocks or malloc()-ed blocks */
        enter_blocking_section();
        /* call C functions */
        leave_blocking_section();
        /* convert C results to Caml data */

For examples of use, you can look at the C stub codes in e.g. otherlibs/unix
in the OCaml distribution.

Hope this answers your question.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml signal handlers (Sys.signal) and C code

[Stefano Zacchiroli]

On Wed, Apr 16, 2003 at 09:16:07PM +0200, Xavier Leroy wrote:
> honored immediately.  However, the C code executed inside the blocking
> section *must not* heap-allocate nor access the Caml heap in any way.
> In practice, this means that all conversions between Caml and C data
> structures must be done outside the blocking section:

Your "in any way" include also read only access (e.g. "Field" invocation
on a caml value allocated outside the blocking section), right?

If this is the case I'm a bit concerned about performances. I have a
piece of C code, invoked by OCaml, that access caml values inside a
loop. To convert this code so that it can be interrupted by ocaml
callbacks I have to enter blocking before each access and exit
afterwards. Is this entering/existing time consuming?

Thanks,
Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml signal handlers (Sys.signal) and C code

[Damien Doligez]

On Friday, April 18, 2003, at 10:41 AM, Stefano Zacchiroli wrote:

> Your "in any way" include also read only access (e.g. "Field" 
> invocation
> on a caml value allocated outside the blocking section), right?

Right.

> If this is the case I'm a bit concerned about performances. I have a
> piece of C code, invoked by OCaml, that access caml values inside a
> loop. To convert this code so that it can be interrupted by ocaml
> callbacks I have to enter blocking before each access and exit
> afterwards.

Actually, you have to leave blocking before the access and enter 
afterwards.


>  Is this entering/existing time consuming?

Unless you use threads, this is only one C function call, two tests,
and three assignments.  Not very time consuming, but you still don't
want to do it within an inner loop.

If this is too much overhead, here is what I would recommend.
Instead of calling leave_blocking_section and enter_blocking_section
around each heap access, you can treat the pair of calls:
    enter_blocking_section ();
    leave_blocking_section ();
as a way to poll for signals.  It will test for any pending signals
and call the handlers immediately.  If you call it once every 100 or
1000 loop executions, the overhead should be quite small.

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml signal handlers (Sys.signal) and C code

[Stefano Zacchiroli]

On Wed, Apr 16, 2003 at 09:16:07PM +0200, Xavier Leroy wrote:
>         enter_blocking_section();
>         /* call C functions */
>         leave_blocking_section();

Ok, thanks Xavier and Damien for the answers.

Let's go to the next level:

1) {enter,leave}_blocking_section are defined in byterun/signal.{h,c}
   and shipped inside libcamlruntime.a. The problem is that signal.h
   isn't shipped in the standard ocaml includes, I can obviously trick
   the C compiler, but is this the intended behaviour?

2) looking at otherlibs/unix/connect.c I see this block of code:

      enter_blocking_section();
      retcode = connect(Int_val(socket), &addr.s_gen, addr_len);
      leave_blocking_section();

   Int_val is used inside the blocking section. I guess that this is
   safe because integers aren't heap allocated. Tell me if I'm wrong.

Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners