On Wed, 01 Feb 2006 12:22:14 +0100 Jan Rychter <[EMAIL PROTECTED]> babbled:
> I've been working on Common Lisp bindings to various EFL libraries, > since I figured that the best way to learn the APIs is by creating > bindings to them and trying them out interactively. > > I've run into one major issue, however. My CL implementation did > strange things (hang, and then crash). It turns out this was because of > Ecore installing signal handlers for every signal out there. Once I > commented out the installation of a handler for SIGSEGV in > ecore_event_signal_init and #undefd SIGRTMIN in ecore_signal.c, the > problems went away and everything started working again. > > Most dynamic languages with a half-decent garbage collector and threads > will need signals. SBCL, which I use, needs SIGSEGV and two > SIGRTs. Comments at the top of ecore_signal.c would seem to indicate > that people experienced problems with Mono and Valgrind already, so this > is likely to become a recurring issue. > > My humble suggestion would be to make all signal handling an optional > feature of Ecore. Not every application that links to Ecore will be a > standalone C app that appreciates Ecore handling the signals for it. signal handling will not become optional. its a core part of ecore. it is absolutley required. there is no signal handler installed by ecore for SIGSEGV - i'm staring at the code right in front of me. it does install RTMIN signal handlers though. this is a service for programs so they dont have to worry about all the issues related to async singal delivery. > BTW, the other place where Ecore assumes a lot about the application is > the ecore_app_restart() call (and other related ecore_app calls). It's > very unlikely that anyone will want to restart a Mono or Lisp > application this way, much less that it will succeed. I feel that these > functions belong in a separate API, useful for standalone C > applications. But at least I have the option of not calling these :) ecore wasnt designed to be used from lisp or mono. you can just not implement the call or create your own layer on top to mimick it correctly within the binding. that call is for c/c++ programs to make it trivial to know how to re-exec themselevs if something goes wrong or they need to - eg e17's restart, or if e17 segv's it can restart itself after catching the error. i see no reason to move these anywhere as you are simply free to not implement them. you are free to not implment every single call in EFL in a binding not everything maps. i can disable the RTMIN signals - but the rest stay - they are used and save pain elsewhere. > --J. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
