public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] pthread_kill and signal lost or pending?
@ 2008-04-07 15:22 Zhichao Hong
  2008-04-07 16:01 ` Nick Garnett
  0 siblings, 1 reply; 4+ messages in thread
From: Zhichao Hong @ 2008-04-07 15:22 UTC (permalink / raw)
  To: ecos-discuss

I am having some confusion about how signals are handled in the POSIX
layer.  Basically, I am not sure whether signals can get lost or not
in the eCos implementation.  I created a producer and consumer
threads.  In the producer, I will increment a counter every time when
pthread_kill is called.  And in the consumer which is blocked on
pselect with no signal blocking (zero signal masked), it also
increment a counter whenever it receives a signal.  I found, the
producer called pthread_kill 20 times whereas the consumer only got it
once or twice.  This leads me to think the signals are either pending
forever or lost.  However, when I introduce a mailbox between the
producer and consumer.  Every time when the producer put the message
in the mailbox and then signals the consumer.  On the other side,
consumer get a message and wait for the next signals.  There are still
less signals received than the ones sent (200 sent vs 5 received).
But it seems that the consumer does manage to consume all the messages
the producer sent even with many lost signals.  Can anyone help
explain why this odd behavior occurs?  This is a ARM7TDMI micro.

-- 
Zhichao Hong, CSDP
zhichao.hong@computer.org

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] pthread_kill and signal lost or pending?
  2008-04-07 15:22 [ECOS] pthread_kill and signal lost or pending? Zhichao Hong
@ 2008-04-07 16:01 ` Nick Garnett
  2008-04-07 16:30   ` Zhichao Hong
  0 siblings, 1 reply; 4+ messages in thread
From: Nick Garnett @ 2008-04-07 16:01 UTC (permalink / raw)
  To: Zhichao Hong; +Cc: ecos-discuss

"Zhichao Hong" <zhichao.hong@gmail.com> writes:

> I am having some confusion about how signals are handled in the POSIX
> layer.  Basically, I am not sure whether signals can get lost or not
> in the eCos implementation.  I created a producer and consumer
> threads.  In the producer, I will increment a counter every time when
> pthread_kill is called.  And in the consumer which is blocked on
> pselect with no signal blocking (zero signal masked), it also
> increment a counter whenever it receives a signal.  I found, the
> producer called pthread_kill 20 times whereas the consumer only got it
> once or twice.  This leads me to think the signals are either pending
> forever or lost.  However, when I introduce a mailbox between the
> producer and consumer.  Every time when the producer put the message
> in the mailbox and then signals the consumer.  On the other side,
> consumer get a message and wait for the next signals.  There are still
> less signals received than the ones sent (200 sent vs 5 received).
> But it seems that the consumer does manage to consume all the messages
> the producer sent even with many lost signals.  Can anyone help
> explain why this odd behavior occurs?  This is a ARM7TDMI micro.


There is no 1-1 correspondence between calls to pthread_kill() and
signal delivery. pthread_kill just sets a bit in the destination
thread's pending signal mask. Many calls can be made before the
handler is called. Individual signals can only be separated if you use
sigqueue() and sigaction(). Even then the number of queued signals is
limited to a small number. This is a property of the POSIX standard
and is true in eCos as well as Linux and BSD.

While signals were a reasonable mechanism for delivering simple
asyncronous events to processes in the original UNIX design, they are
poorly suited to multithreaded or real time systems. Efforts to fix
this up in BSD, SysV and POSIX have not been successful. Signal
support in eCos is really only present to help porting existing
code. Signals should never be used for new code. Avoid them!

-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
**  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
**  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] pthread_kill and signal lost or pending?
  2008-04-07 16:01 ` Nick Garnett
@ 2008-04-07 16:30   ` Zhichao Hong
  2008-04-07 16:36     ` Nick Garnett
  0 siblings, 1 reply; 4+ messages in thread
From: Zhichao Hong @ 2008-04-07 16:30 UTC (permalink / raw)
  To: Nick Garnett; +Cc: ecos-discuss

Nick,

Thank you for you quick response!  Is the sigaction and sigqueue in
eCos process wise or thread wise?  If sigqueue is called, is it for
the whole process which is always 0 in eCos get the signal?

Zhichao

On Mon, Apr 7, 2008 at 10:25 AM, Nick Garnett <nickg@ecoscentric.com> wrote:
>
> "Zhichao Hong" <zhichao.hong@gmail.com> writes:
>
>  > I am having some confusion about how signals are handled in the POSIX
>  > layer.  Basically, I am not sure whether signals can get lost or not
>  > in the eCos implementation.  I created a producer and consumer
>  > threads.  In the producer, I will increment a counter every time when
>  > pthread_kill is called.  And in the consumer which is blocked on
>  > pselect with no signal blocking (zero signal masked), it also
>  > increment a counter whenever it receives a signal.  I found, the
>  > producer called pthread_kill 20 times whereas the consumer only got it
>  > once or twice.  This leads me to think the signals are either pending
>  > forever or lost.  However, when I introduce a mailbox between the
>  > producer and consumer.  Every time when the producer put the message
>  > in the mailbox and then signals the consumer.  On the other side,
>  > consumer get a message and wait for the next signals.  There are still
>  > less signals received than the ones sent (200 sent vs 5 received).
>  > But it seems that the consumer does manage to consume all the messages
>  > the producer sent even with many lost signals.  Can anyone help
>  > explain why this odd behavior occurs?  This is a ARM7TDMI micro.
>
>
>  There is no 1-1 correspondence between calls to pthread_kill() and
>  signal delivery. pthread_kill just sets a bit in the destination
>  thread's pending signal mask. Many calls can be made before the
>  handler is called. Individual signals can only be separated if you use
>  sigqueue() and sigaction(). Even then the number of queued signals is
>  limited to a small number. This is a property of the POSIX standard
>  and is true in eCos as well as Linux and BSD.
>
>  While signals were a reasonable mechanism for delivering simple
>  asyncronous events to processes in the original UNIX design, they are
>  poorly suited to multithreaded or real time systems. Efforts to fix
>  this up in BSD, SysV and POSIX have not been successful. Signal
>  support in eCos is really only present to help porting existing
>  code. Signals should never be used for new code. Avoid them!
>
>  --
>  Nick Garnett                                      eCos Kernel Architect
>  eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
>  Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
>  Registered in England and Wales: Reg No 4422071.
>  **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
>  **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
>
>



-- 
Zhichao Hong, CSDP
zhichao.hong@computer.org

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] pthread_kill and signal lost or pending?
  2008-04-07 16:30   ` Zhichao Hong
@ 2008-04-07 16:36     ` Nick Garnett
  0 siblings, 0 replies; 4+ messages in thread
From: Nick Garnett @ 2008-04-07 16:36 UTC (permalink / raw)
  To: Zhichao Hong; +Cc: ecos-discuss

"Zhichao Hong" <zhichao.hong@gmail.com> writes:

> Nick,
> 
> Thank you for you quick response!  Is the sigaction and sigqueue in
> eCos process wise or thread wise?  If sigqueue is called, is it for
> the whole process which is always 0 in eCos get the signal?

sigqueue() only delivers to the whole process. So you have to select
which thread gets the signal by manipulating the signal masks. Signal
handlers are global, as POSIX requires. Assuming anything about which
thread a signal handler is run in is not good practice. If you want to
restrict signal delivery to a particular thread, it is often more
sensible to use sigwait().

eCos only allows a pid value of 0 for any of the signal functions
since there is notionally only a single process.

-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
**  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
**  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-04-07 16:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-04-07 15:22 [ECOS] pthread_kill and signal lost or pending? Zhichao Hong
2008-04-07 16:01 ` Nick Garnett
2008-04-07 16:30   ` Zhichao Hong
2008-04-07 16:36     ` Nick Garnett

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).