This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: cyg_io_read blocking
- From: Bart Veer <bartv at ecoscentric dot com>
- To: raghu_dk at yahoo dot com
- Cc: ecos-devel at sources dot redhat dot com
- Date: Fri, 8 Apr 2005 13:33:35 +0100 (BST)
- Subject: Re: cyg_io_read blocking
- References: <20050408104124.12321.qmail@web40423.mail.yahoo.com>
>>>>> "Raghu" == Raghu <raghu_dk@yahoo.com> writes:
Raghu> Sample code of "cyg_io_read", "cyg_io_write" that blocks
Raghu> when a thread is spawned, but if called from a functions
Raghu> dosent.
Raghu> void cyg_user_start( void )
Raghu> {
Raghu> cyg_thread_create( 4, serial_thread_handler, ...
Raghu> );
Raghu> cyg_thread_resume( handle );
Raghu> }
Raghu> void serial_thread_handler( cyg_addrword_t data )
Raghu> {
Raghu> cyg_io_lookup( &hdl );
Raghu> for( ; ; ){
Raghu> cyg_io_read( hdl, &ch, &len );
Raghu> cyg_io_write( hdl, &ch, &len );
Raghu> }
Raghu> }
Raghu> But if "serial_thread_handler" is directly called from
Raghu> "cyg_user_start" as a function call, there is no
Raghu> issues.
cyg_user_start() is run during system startup, before the scheduler is
started or interrupts are enabled. There is no way for the system to
block at this time. Blocking involves transferring control to another
thread, possibly the idle thread, and that cannot happen if the
scheduler has not yet started.
A typical cyg_user_start() performs little if any I/O. Instead it just
performs operations that affect the cpu and memory, e.g. starting one
or more threads. Sometimes I/O at this stage cannot be avoided, but it
will have to be non-blocking I/O in a polling loop.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts