Re: Asking for comments on POSIX SIGEV_THREAD implementation

[Nick Garnett <nickg at ecoscentric dot com>]

Dan Jakubiec <djakubiec@yahoo.com> writes:

> I recently submitted a patch that added support for
> SIGEV_THREAD handling in the POSIX subsystem.  I
> realized that the enhancement I submitted had a
> problem, though, which I'm working on fixing right now
> (luckily though, I think my patch was ignored). 
> Although my patch does not exhibit any noticeable
> problems, it nevertheless creates threads from DSR
> contexts which is not allowed.

As it happens I was taking a look at this patch today. You are right
in than the call to cyg_sigqueue() from the timer alarm_action() is
not allowed.

> 
> In any case, I wanted to get some feedback on the
> implementation of this feature.  The basic problem is
> that processing a SIGEV_THREAD requires a new thread
> to be started and eCos threads may only be started out
> of thread context.  SIGEV_THREAD events can currently
> occur in two places: as a result of timer expiration
> or from posting to a POSIX message queue.  Both of
> these can happen out of DSR context so there needs to
> be a way to defer processing of SIGEV_THREAD until we
> get to a good thread context.
> 
> POSIX SIGEV_SIGNAL signals are handled via the POSIX
> ASR, but this won't work for SIGEV_THREAD since it
> isn't valid to wake up any of the POSIX threads to do
> this work.
> 
> So it seems to me that to support SIGEV_THREAD
> notifications a dedicated POSIX thread must be created
> to receive and process the SIGEV_THREAD events.  In
> broad terms, my idea was to:
> 
> 1) Create a POSIX "system" thread at init time for
> processing these requests.  (In the future perhaps it
> might also be used for other POSIX functionality?)
> 
> 2) This thread will be executed at the highest system
> priority and will wait on a POSIX semaphore to process
> events.
> 
> 3) SIGEV_THREAD events will post a semaphore event to
> wake up the system thread.
> 
> 4) Upon wakeup, the system thread will scan the timer
> list for expired timers with SIGEV_THREAD notification
> types.  I'm not exactly sure what needs to happen for
> the message queues, but presumably something similar.
> 
> 
> In general, does this approach sound reasonable?  Or
> can someone think of a better approach?  Comments are
> appreciated.

When I designed the POSIX support I wanted to avoid having a special
posix service thread, this raises all sorts of synchronization and
priority inversion problems. The extra stack and data structures
needed for this thread also impose a significant extra memory
burden. Hence the use of ASRs to piggyback asynchronous processing
onto existing threads, and the way that pthread_reap() is called at
opportune moments.

Also, SIGEV_THREAD is not really consistent with the needs of a real
time system. It requires significant resource allocation and data
structure initialization right in the middle of what could be a
critical path. What happens if there is insufficient memory or no more
thread table slots is not well defined. It is really there for use in
non-real time resource-rich Unix environments where this is not going
to be a problem. In a system like eCos it is much more sensible to
preallocate the threads used to service any signals and use sigwait()
and friends to respond to them. That, after all, is why those
functions were added.

For these reasons I was quite happy to leave the SIGEV_THREAD stuff
unimplemented.

If you want to submit a patch I will certainly look at it. However, I
think it should all be controlled by a config option that is defaulted
to off so that users do not pay the code and memory price of what is
likely to be a seldom used feature.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts