Enlightenment

On Mon, 24 Jan 2011 20:56:25 +0900
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().
> 
> A fix for before or after 1.0...?
> 
> thanks,
> 
> Mike
> 
> 
> btw. the SIGRTMIN is totally borken and probably should be deleted
I'll look a bit more carefully later, but it looks like some great cleanup work
that would be nice to see in 1.0 since the current code is a total mess.

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

On Mon, 2011-01-24 at 06:58 -0500, Mike Blumenkrantz wrote:
> I'll look a bit more carefully later, but it looks like some great cleanup work
> that would be nice to see in 1.0 since the current code is a total mess.
> 

We were supposed to release yesterday, I don't think it's a good time
for redesigning stuff. Although I truly trust mike (not you!) and the
quality of his work, I think it's a case of too many changes too close
to release, but hey, I don't even believe in big releases, so.. :P

--
Tom.

On Mon, 24 Jan 2011 21:10:30 +0900
Tom Hacohen <tom.hacohen@...> wrote:

> On Mon, 2011-01-24 at 06:58 -0500, Mike Blumenkrantz wrote:
> > I'll look a bit more carefully later, but it looks like some great cleanup
> > work that would be nice to see in 1.0 since the current code is a total
> > mess.
> > 
> 
> We were supposed to release yesterday, I don't think it's a good time
> for redesigning stuff. Although I truly trust mike (not you!) and the
> quality of his work, I think it's a case of too many changes too close
> to release, but hey, I don't even believe in big releases, so.. :P
> 
> --
> Tom.
> 
Isn't "just before release" the best time to be fixing stuff that is messy?

-- 
Mike Blumenkrantz
Zentific: NULL pointer dereferences now 50% off!

On Monday, 24 January 2011, at 14:56:52 (-0500),
Mike Blumenkrantz wrote:

> Isn't "just before release" the best time to be fixing stuff that is messy?

No.  Just before release isn't the best time to fix anything.  It's an
appropriate time to fix critical bugs, but it's not even an
appropriate time to fix "messy," let alone the best time.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
Linux Server/Cluster Admin, LBL.gov       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "I disapprove of what you say, but I will defend to the death your
  right to say it."                                        -- Voltaire

On Mon, 2011-01-24 at 14:56 -0500, Mike Blumenkrantz wrote:
> Isn't "just before release" the best time to be fixing stuff that is messy?
> 

Not in my pov, so close to release we should try to avoid doing big
changes because big changes sometimes (usually) bring bugs in.

But what a "big change" is, is subjective so maybe someone else has a
better interpretation of the term that considers this one as a "small
change" :)

--
Tom.

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.

>
> A fix for before or after 1.0...?

After, for sure.



thanks, Mike

Lucas De Marchi

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.

thanks,

Mike

On Tue, 25 Jan 2011 13:52:22 +0900 Mike McCormack <mj.mccormack@...>
said:

> 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@...

On 01/31/2011 07:29 PM, Carsten Haitzler (The Rasterman) wrote:

> 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.

Attached.

The handlers were all merged into one, which sends the signal information over
a pipe.

thanks,

Mike

On Tue, 01 Feb 2011 14:44:10 +0900 Mike McCormack <mj.mccormack@...>
said:

in svrn...

> On 01/31/2011 07:29 PM, Carsten Haitzler (The Rasterman) wrote:
> 
> > 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.
> 
> Attached.
> 
> The handlers were all merged into one, which sends the signal information over
> a pipe.
> 
> thanks,
> 
> Mike


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...