#14055: Fix sage-cleaner
------------------------------------------------+---------------------------
Reporter: jdemeyer | Owner: leif
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-5.10
Component: scripts | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers: John
Palmieri, Leif Leonhardy, Volker Braun
Authors: Jeroen Demeyer, Volker Braun | Merged in:
Dependencies: | Stopgaps:
------------------------------------------------+---------------------------
Comment (by nbruin):
The last time I looked at it, ECL as a library with multithread support is
rather fundamentally incompatible with the way we use it. As far as I
know, if thread support is enabled then ECL expects one (dedicated?)
thread to handle asynchronous signals and I think that thread may even be
split off when there's otherwise only one thread running. I don't see how
to consolidate that with our own signal management. The solution up to
know has been to only use ECL in single threaded mode, which may mean
building it without thread support. I know ECL has been moving towards
multithreadedness. However, as an "embeddable" lisp there's a good
argument they should also keep a strictly single-threaded version as an
option and I hope they're continuing with that (perhaps sending a message
that we really appreciate single threadedness might help).
Our signal switching code has been a little behind the times for a while
already. Some improvements were suggested here:
http://comments.gmane.org/gmane.lisp.ecl.general/8211
That code might be outdated already as well.
What is the hypothesis here, by the way? That an event triggered by sage-
cleaner produces a signal meant for our own signal handler that happens to
end up in with the ecl signal handler? If that's the problem I see no way
around it. Then we just need to write our own signal handler to always be
in control, keeping flags on whether some signals might have to be
dispatched to ECL and do so for signals we deem appropriate for that.
That's major surgery (I've actually been surprised we were able to avoid
that for so long and I hope we can continue)
I guess normally, ECL expects SIGCHLD to be ignored. We apparently set a
different mask? Changing to ECL's signal mask would include ignoring a
SIGCHLD if it happens to be in control when the signal arrives. Can we
afford to? Do we already try to do that? In that case is the problem that
the signal arrives in a small window where we've switched handlers but not
masks? Then we should be a little more careful about the switch, i.e.,
perhaps disable signals during the switch completely.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14055#comment:101>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
