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]
Other format: [Raw text]

Re: POSIX timer callback context


I'm not really resistant to it, (nor should my resistance really be a factor 
as I have never contributed one line to ECOS, I am evaluating it as a 
platform for some future work, but I have done a fair amount of POSIX related 
work in my company's proprietary RTOS and we ran into similar issues.) I just 
wanted to point out one possible issue.  in fact, I wish POSIX were 
explicitely spec'd to do what you've suggested as well as many other thread 
sanity behaviors WRT signals.  I think this would make a great config option 
(something like "treat threads as procs WRT signals").

In general, whenever we (my company) have been working on a standards related 
API, we have always strived to folow the principle of least surprise, i.e. 
our OS shouldn't surprise our customers with unusual behavior, even when that 
behavior is technically legal in the spec and we think that the behavior is 
benign or even beneficial.

another interesting hole in the POSIX spec WRT timers is calling 
timer_settime() after timer expiration, but before completion of the signal 
handler.  this is "undefined" in POSIX and every OS does something a little 
different.  it is technically legal for the OS to panic in this situation, 
but evil (assert I don't know what ecos does here). this is most commonly 
seen when someone has siglongjmp()'d away from the handler.


On Monday 03 November 2003 12:57, Dan Jakubiec wrote:
> Mark,
>
> Yes, I see your point.  From that perspective, perhaps
> this patch isn't really suitable for public
> submission.
>
> Our app is actually designed to be run as multiple
> processes, not threads.  The only real reason I went
> down this road is because we have 24 threads and not
> enough signals.  It seemed to me that since the signal
> delivery behavior is not really defined, that making
> it more deterministic wouldn't break anything, and
> would be a clean way to side-step the issue until we
> could implement more full-fledged POSIX process
> support.
>
> Since our signal usage is minimal (we just use them to
> wake up pselect() calls), our application is still
> portable, with the qualification that in a different
> environment our tasks get started as processes, not
> threads.
>
> In any case, my orginal thinking was that providing
> some level of determinism to the timers provides the
> app writer with some more options and, technically
> speaking, doesn't really change or break any existing
> behavior (since it's undefined to begin with).  Also,
> the POSIX spec made vague reference to "actions
> attributable to a particular thread", which made the
> whole thing seem rather logical.
>
> So I don't know. At this point I guess I'm on the
> fence about whether to submit the patch or not.  I
> understand the resistance coming from you and Nick on
> the whole issue, and I concur with the "funny feeling"
> of it all.  My thinking is that it doesn't hurt
> anything and may help someone else in a similar
> situation to mine, but I'm also okay with just keeping
> the patch private to our source base.
>
> What do you guys think?  Any strong opinions on how to
> proceed from here?
>
> Thanks again for all the input.

-- 
/**************************************************\
**     Mark Salisbury     ||       mbs@mc.com     **
** Thanks to all who sposored me for the Multiple **
** Sclerosis ride.  This year we raised $4,680!!  **
\**************************************************/

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


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