On Tue, 25 Jan 2011 13:52:22 +0900 Mike McCormack <mj.mccormack@...>
> On 01/25/2011 12:10 PM, Lucas De Marchi wrote:
> > On Mon, Jan 24, 2011 at 9:56 AM, Mike McCormack
> > <mj.mccormack@...> wrote:
> >> The way ecore handles signals is racy.
> >> The attached patch uses a pipe to avoid races between signals and
> >> select/poll().
> > Couldn't we use signalfd instead? It's the most clean way I know.
> Clean, but not portable, as I understand. I could add it with a fallback
> to the pipe method.
> There's actually quite a bit of cleaning up to do for ecore signal handling.
> I'm not even sure that it's a good idea for a library (or framework) to
> be messing with signal handlers without an explicit request from the
> application using it.
> >> A fix for before or after 1.0...?
> > After, for sure.
> I agree. Was testing the general consensus. Will queue this and work on
> cleaning up the rest of it.
got a cleaned up patch? yours doesnt apply at all. also i think you removed
most but not all the handlers. _ecore_signal_callback_sigrt still had a
prototype at any rate reading your diff.
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...