#182 ecl should by default not handle signals in different thread

open
nobody
None
5
2012-07-25
2012-05-12
Paulo Andrade
No

I am working on porting sagemath to fedora, and in a previous work, it was
required to patch sagemath ecl initialization, see
http://trac.sagemath.org/sage_trac/ticket/11752

Now, when attempting to generate a request for enhancement in fedora, to
build maxima with ecl support, I found again the
problem, as maxima would dead lock in make check. Probably related to
http://www.mail-archive.com/ecls-list@lists.sourceforge.net/msg00644.html
or at least same symptoms.

The attached patch corrects the problem for me, and allows building maxima
with ecl enabled in fedora.

Discussion

1 2 > >> (Page 1 of 2)
  • I am afraid this is not a patch, but a hack which is probably hiding some other problem. POSIX does not allow us to run any useful code in a signal handler and in the future all signals will be handled in separate threads.

     
  • Paulo Andrade
    Paulo Andrade
    2012-05-13

    Do you have a suggestion of a existing one, or how to create a very small,
    preferably self contained test case to verify the problem is not happening?

    If I understand correctly, at least in my current test system with fedora 16

    $ rpm -q glibc
    glibc-2.14.90-24.fc16.6.x86_64

    it is showing the behaviour that was expected to exist only in older glibc.
    Such a test case would be filled as bug report to glibc, and hopefully added
    to regression tests.

     
  • Paulo Andrade
    Paulo Andrade
    2012-05-13

    You may also want to experiment with semaphores. I have a toy and
    work in progress C/C++ like language, where I just adapted the
    example from "David R. Butenhof. Programming with POSIX Threads.
    Addison-Wesley. ISBN 0-201-63392-2".
    It uses sigsuspend, but I also wrote a version using semaphores
    because helgrind understand the semantics of semaphores, what
    makes it a lot easier to have it detecting racing conditions.
    But I do not enable the semaphore version other than for debug
    builds because it dead locks from time to time, apparently behavior
    varies depending on kernel and glibc version, and the mix of
    semaphores and mutexes.

     
  • We cannot use POSIX semaphores in ECL because they are not available everywhere --for instance older versions of OS X--. Also past experiences with interrupts and POSIX threads have made me remove all dependencies on them.

     
  • Paulo Andrade
    Paulo Andrade
    2012-05-14

    I tried to adapt the patch to ecl-12.2.1 but it got too confusing after
    things like s/ecl_option_values[(.*)]/ecl_get_option(\1)/, among a few
    others...
    Examples
    /home/pcpa/rpmbuild/BUILD/ecl-12.2.1/src/c/unixint.d:208:1: note: expected 'void ()(int, struct siginfo_t , void )' but argument is of type 'void ()(int)'
    /home/pcpa/rpmbuild/BUILD/ecl-12.2.1/src/c/unixint.d:588:4: error: too few arguments to function 'si_wait_for_all_processes'
    /home/pcpa/rpmbuild/BUILD/ecl-12.2.1/src/c/unixint.d:593:20: error: 'struct cl_core_struct' has no member named 'known_signals'

     
  • Sorry, I assumed you were using a more recent version of ECL (it would have been nice to check it with it, outside sage, just to ensure things will be ok). In any case, I would be very grateful if you could test the new patch that I produced with ecl-12.2.2

     
1 2 > >> (Page 1 of 2)


Anonymous


Cancel   Add attachments