On Thu, 09 Dec 2010 13:36:14 +0900 Mike McCormack <mj.mccorm...@samsung.com> said:
> On 12/09/2010 11:57 AM, Mike Blumenkrantz wrote: > > >> _ecore_main_loop_shutdown(); > >> _ecore_main_loop_init(); > >> } > > > Okay, but the only place that _ecore_main_fdh_poll_del can be called from is > > ecore_main_fd_handler_del. If a bad fd gets into epoll and then is > > selected on without being removed, it will just loop infinitely without > > ever being able to be removed, just like we're seeing in this bug. Might > > be good to add shutdown+init inside bads_rem if no bads are found, yes? > > Getting a stale fd in epoll is a bug. It means somebody closed the fd without > removing it from ecore_main_loop, and that should be fixed. > > Rather than adding more bandaids, it would be better to fix the root cause of > the problem. indeed you are right. what would be RIGHT to do here is like the rest of EFL and where it has magic number checks. this is similar. when it encounters such a bad fd ecore could/should blurt out an ugly warning and if ECORE_ERROR_ABORT is set in the env call abort instantly there - thus providing easy debugging. it CAN now clean up and march on after a rebuild. it gave the developer a good chance to fix things. at least it is robust enough to march on with no side effects from that point. zmike: you may want to change your proposal to be like the above. i'd be more comfortable with it that way. it solves the "bad userspace code" problem as well as providing good debuggability (mike's point). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
