On Wed, 01 Feb 2006 14:57:52 +0100 Jan Rychter <[EMAIL PROTECTED]> babbled:
> > 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. i do disagree - the whoel signal delivery system in unix is out of whack with fd's and select. it makes basic things like catching child process exits a pain. you end up having to catch at least some. sigterm/quit/whatever u'd want put within the main loop so u dont shut down and save config in the middle of some routine that is futzing with internal structs u are about to save. this serialises thsi into an event steram and avoids problems in the long run by giving you a well defined location you get all events from in a consistent manner. it means troping about over unix land and poiking in dark singy holes - but the result at the top layer is nicer than it was before :) -- ------------- 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
