From 3bf27c93ac4de57623809b71517116d51465f0e1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 17 Mar 2012 12:31:07 +0100 Subject: IRC bits. --- open_issues/boehm_gc.mdwn | 42 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-) (limited to 'open_issues/boehm_gc.mdwn') diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn index 19bd1b21..e7f849f2 100644 --- a/open_issues/boehm_gc.mdwn +++ b/open_issues/boehm_gc.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -281,3 +281,43 @@ It has last been run and compared on 2010-11-10, based on CVS HEAD sources from Git branches (2010-12-15: last change 2009-09). * + + +## IRC, OFTC, #debian-hurd, 2012-02-05 + +[[!tag open_issue_porting]] + + youpi: i think i found out the possible cause of the ecl and + mono issuess + -s + oh + basically, we don't have the realtime signals (so no + SIGRTMIN/SIGRTMAX defined), hence things use either SIGUSR1 or + SIGUSR2... which are used in libgc to resp. stop/resume threads when + "collecting" + i just patched ecl to use SIGINFO instead of SIGUSR1 (used when + no SIGRTMIN+2 is available), and it seems going on for a while + uh, why would SIGINFO work better than SIGUSR1? + it was a test, i tried the first "not common" signal i saw + my test was, use any signal different than USR1/2 + ah, sorry, I hadn't understood + you mean there's a conflict between ecl and mono using SIGUSR1, as + well as libgc? + yes + for example, in ecl sources see src/c/unixint.d, + install_process_interrupt_handler() + SIGINFO seems a sane choice + SIGPWR could have been a better choice if it was available :) + i would have chose an "unassigned" number, say SIGLOST (the + bigger one) + 10, but it would be greater than _NSIG (and thus discarded) + not a good idea indeed + it seems that linux, beside the range for rt signals, has some + "free space" + i'll start now another ecl build, from scratch this time, with + s/SIGUSR1/SIGINFO/ (making sure ctags won't bother), and if it works i'll + update svante's bug + + mmap(...PROT_NONE...) failed + hmm... + apparently enabling MMAP_ANON in mono's libgc copy was a good + step, let's see -- cgit v1.2.3