This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: sscanf() vs. fgetc()


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]



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]