On Tue, 01 Feb 2011 14:44:10 +0900 Mike 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
> >
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 i
On Tue, 25 Jan 2011 13:52:22 +0900 Mike McCormack
said:
> On 01/25/2011 12:10 PM, Lucas De Marchi wrote:
> > On Mon, Jan 24, 2011 at 9:56 AM, Mike McCormack
> > wrote:
> >>
> >> The way ecore handles signals is racy.
> >> The attached patch uses a pipe to avoid races between signals and
> >> se
On 01/25/2011 12:10 PM, Lucas De Marchi wrote:
> On Mon, Jan 24, 2011 at 9:56 AM, Mike 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 w
On Mon, Jan 24, 2011 at 9:56 AM, Mike 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, f
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" i
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 ti
On Mon, 24 Jan 2011 21:10:30 +0900
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 wer
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 r
On Mon, 24 Jan 2011 20:56:25 +0900
Mike 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 p
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
>From 1a21c643e08e325b2773e53ecde27bcf46ca5148 Mon Sep 17
11 matches
Mail list logo
