This is the mail archive of the ecos-devel@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]
Other format: [Raw text]

Asking for comments on POSIX SIGEV_THREAD implementation


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.

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.

--
Dan Jakubiec
Systech Corp


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


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