This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: sscanf() vs. fgetc()
- To: ecos-discuss at sources dot redhat dot com
- Subject: Re: [ECOS] sscanf() vs. fgetc()
- From: Peter Graf <p dot graf at itknet dot de>
- Date: Thu, 12 Jul 2001 12:04:48 +0200
- References: <F38jaS36Il06sIQrttD00011011@hotmail.com>
Jonathan Larmour wrote:
>Is the fileio package enabled in your configuration?
Yes.
Peter
>> after problems in a large context, I have cut things down to a short
>> example for a phenomenon I can't explain myself.
>>
>> I create and resume a new thread which uses fgetc() on a serial port, in an
>> infinite loop.
>> This new thread has a higher priority than the old one.
>> If no characters are received, fgetc blocks and the old thread continues.
>>
>> So far so good.
>>
>> But when I use sscanf() in the old thread, it hangs.
>> Even if the new process completes fgetc(), because characters are received,
>> the old process won't get any further.
>>
>> My first explanation was, that fgetc() might poll and doesn't allow to
>> schedule lower priority threads. Obviously, this was wrong, because the old
>> thread runs fine, as long as it doesn't use sscanf(), even if it calls C
>> Library functions like sprintf().
>>
>> My second explanation was that there might be a resource conflict between
>> fgetc() and sscanf(). (I have no idea why there should be such a conflict!)
>> So I placed a scheduler lock around sscanf(). It still hangs. (And the
>> higher priority task as well.)
>>
>> I found two ways to keep sscanf() from hanging, which is giving the fgetc()
>> thread a lower priority, or add a cyg_thread_delay() after the fgetc().
>>
>> It is not that I could not work around this phenomenon, but I am concerned
>> of unexpected conflicts between C Library functions running in different
>> tasks. So I would be happy if someone can enlighten me...
>>
>> (Assertions give no clue. Target is Hitachi SH3.)
>>
>> [snip]