On 20/06/07, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> [ ... ]
> > xnintr_attach/detach()).. your approach does increase a worst case
> > length of the lock(&intrlock) --> unlock(&intrlock) section... but
> > that's unlikely to be critical.
> >
> > I think, the patch I sent before addresses a reported earlier case
> > with xnintr_edge_shirq_handler().. but your approach does make code
> > shorter (and likely simpler), right? I don't see any problems it would
> > possibly cause (maybe I'm missing smth yet :)
> I must confess I didn't get your idea immediately. Later on (cough,
> after hacking my own patch, cough) I had a closer look, and it first
> appeared fairly nice, despite the additional "ifs". But then I realised
> that "end == old_end" may produce false positives in case we have
> several times the same (and only the same) IRQ in a row.
> So, I'm afraid
> we have to live with only one candidate. :->

It's not clear, can you elaborate your (non-working) scenario in more
details? :-)

Note: I sent the second patch with the following correction :

                } else if (code == XN_ISR_NONE && end == NULL) {
                        end = intr;
+                        old_end = NULL;

I don't see why this idea can't work (even if I made yet another error).
Under some circumstances the following code will be triggered to end a
loop even when 'end' is still valid

                        if (end && old_end == end)
                                intr = NULL;

_but_ it'd be exactly a case when "intr == end" and hence, the loop
would be finished anyway by the "while (intr && intr != end)"
condition.. So sometimes it acts as yet _another_ check to exit the
loop, IOW "while (intr && intr != end)" may be converted to just
"while (intr)".

> Jan

Best regards,
Dmitry Adamushko

Xenomai-core mailing list

Reply via email to