[ECOS] Re: cyg_selwakeup and performance impact?
Sun Feb 8 14:17:00 GMT 2009
The root cause of this problem has been fixed in the latest serial.c
rev 1.28. The problem is caused by race condition in the
serial_select. The problem is not about "draining the input buffer".
And the unnecessary wake up is not needed. Glad that I don't have to
worry about the performance (thread rescheduling) penalty and its
unknown consequences. Sorry about the confusion.
Zhichao Hong, CSDP
On Sat, Oct 18, 2008 at 9:57 PM, Tom Anderson <firstname.lastname@example.org> wrote:
>>> serial_rcv_char() that wake up the thread in serial.c:
>>> //if( cbuf->nb == 0 )
>>> cyg_selwakeup( &cbuf->selinfo );
>> Surely the best thing is to find out why that thread isn't getting woken up
> when there's data?
> For whatever
> problem you are trying to address, this kind of "fix" will cause more troubles than it helps.
> Select only tells you that something available (readable) in your case. Once you passed the
> select, the best thing is to read the buffer empty. And that is one of the reason you are selecting anyway.
> One thing you can check is why the read did not read all the data it needs before put back to select again.
> Is the read interrupted by signals or something else?
> Actually if this is the cause, changing the eCos as you've shown will not actually help. Even when it works, it is merely
> a luck in a noisy system (many wake-ups) as you mentioned. But these many wake-ups may still be not enough. Or you could
> see some odd issue in "unrelated" area.
> I also think the best way is to address the application issue. And I believe, changing eCos in this way will make
> your application very hard to port to future releases or similar UNIX like
> Just my 2 cents.
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss