Re: [Caml-list] BUG in unix.ml (was: strange errors when linking lwt.unix)

[oliver <oliver@first.in-berlin.de>]

On Fri, Mar 15, 2013 at 03:44:14PM +0000, Gabriel Kerneis wrote:
> Oliver,
> 
> > I don't know why you are telling me this.
> > i did not asked about it.
> 
> Jérémie is kindly trying to show you why you are mistaken.

I did not see it from his explanation that signal(2) is not called.



> When you say:
> 
> > > > Just by your activation of signal function - not blocking, but handling
> > > > "Sys.Signal_handle" but with the unreliable signal semantics this has
> > > > cause the problems.
> > > >
> > > > signal(2) opened the pandoras box.
> 
> This is wrong.  Because OCaml does not call signal(2).  At all.  So there is no
> "pandora box" to open, no "unreliable signal semantics" used.
> 
>           Sys.set_signal = sigaction(2)
>                          ≠ signal(2)


From this kind of explanation I see more.

The problem occures when using the signal handler from Sys,
not from unix module.
It was stated that the unix module is doing things wrong.
But the Unix signalling mechanism was not used.

I wait for an example which uses Unix module for the signals
and fails.

have not seen it so far.

So, then interaction of Sys- and Unix.-module may be a problem.

But the Code did not used Unix-module.

So it's also wrong to state Unix module makes problems and is buggy,
if the example don't uses it for the signal handling.

I had the assumption that Sys-module uses signal(2).
It may be wrong (did not eplored the sources).
But then there is the problem, not in Unix-module.

Also I wonder why threads were mentioned.
In the test code via the list was nothing from Thread-module
involved.



> 
> (And sigprocmask(2) is irrelevant here: it is also part of the "reliable
> semantics", but does something different from sigaction(2), as Jérémie told
> you.)

I never said that sigrpocmask or sigactiona re non-reliable.

signal(2) is non-reliable.
That was my point, toigether with Assumption of signal(2) in Sys-sighandlers.




> 
> > But if you wish to explain it to yourself, go on.
> 
> You are not only rude but also completely missing the point here.

You also missed my point.

What I have overlooked at the beginning was, that
Sys.* was used and not Unix.*
and when I saw that later, I was a bit astouned and confused.

So I removed the Sys.* signal stuff.
Then there was no problem in the code.

I'm still waiting for the code that shows that unix.ml is buggy.

If Sys.<signalstuff> is also using sigprocmask/sigactio/sig[^nal]foobar
then Sys.* is the problem.

That was my point.

Maybe I was not clear in explaining this.

So... back to beginning of the Thread:  where is Unix module failing on signals?

Ciao,
   Oliver