> 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.
You're right and I was wrong (surprise surprise) -- it does install one if you ask it by calling ecore_event_signal_init(), but it doesn't do that by default. I didn't realize that. > 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. Right. Well, it was never my goal to create bindings to all of ecore. The thing is, if I want to use Evas and Ecore_Evas, I end up pulling in Ecore. At the bindings level the only thing I might need is ecore_init() and ecore_shutdown(), but I'm not happy with Ecore doing things I didn't ask for (such as intercepting signals). I can see how this makes perfect sense if you're building an application with Ecore in the center, but it is much less sensible if you need to use Evas from a different language. I've been really impressed with the overall design of EFL -- most libraries have well-defined and easy to understand APIs and concerns are clearly separated. Ecore seems to be an exception: in my humble opinion it mixes application-level functionality (interception of all signals, ecore_exe* and ecore_app* functions) with library functionality (event handling, event loop). The former is used by applications, the latter by libraries on top of Ecore. > i can disable the RTMIN signals - but the rest stay - they are used > and save pain elsewhere. If you disagree with my comments about separation of concerns, then please at least disable RTMIN and RTMIN+1 -- that goes a long way towards making things work for us folks with garbage collection. And please don't catch SIGSEGV in the future. --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
