2016-07-28 5:03 GMT-07:00 Christos Zoulas <chris...@astron.com>: > In article < > ca+sxe9secy0w9cezsqxpoc2w1ypvl+inqt5rgiyap8ahzgd...@mail.gmail.com>, > Charles Cui <charles.cui1...@gmail.com> wrote: > >-=-=-=-=-=- > > > >This patch > > > https://github.com/ycui1984/posixtestsuite/blob/master/patches/REALTIME_SIGNAL/0007-improve-efficiency.patch > > > >improves the code efficiency and removes duplicate search in the signal > >queue. > > yes, but where does the ksiginfo get freed now since you removed: > - ksiginfo_free(ksi); /* XXXSMP */ > well, the original logic only finds one target signal and return true, at that time ksi is pointing to some data, in my case, I need to loop all signals to return the count, and at the end of the loop, ksi is set to be NULL.
> > christos > > > >2016-07-27 10:34 GMT-07:00 Charles Cui <charles.cui1...@gmail.com>: > > > >> Yeah, I will try to improve the code efficiency. > >> > >> 2016-07-27 10:14 GMT-07:00 Christos Zoulas <chris...@zoulas.com>: > >> > >>> On Jul 27, 8:23am, charles.cui1...@gmail.com (Charles Cui) wrote: > >>> -- Subject: Re: updates? > >>> > >>> | 3. there will be a concern if we count the number of signals each > time, > >>> | but this sigcnts logic may can be merged with siggetinfo. > >>> > >>> Can you try doing that? > >>> > >>> | 2. I can add kassert around ret. > >>> | 1. I know sp cannot be NULL, and if it is NULL, the sigcnt is zero, > >>> what do > >>> | you mean of code would die (which piece of code)? > >>> > >>> I mean the code that unconditionally deleted the signal from the set. > >>> > >>> christos > >>> > >> > >> > > > >-=-=-=-=-=- > > > >
