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
Zhichao Hong, CSDP
[email protected]



On Sat, Oct 18, 2008 at 9:57 PM, Tom Anderson <[email protected]> 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
>  OSes.
>
> Just my 2 cents.
>
> -Tom
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply via email to