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]

Re: PTHREAD_INHERIT_SCHED


Nick Garnett wrote:
Jonathan Larmour <jifl@eCosCentric.com> writes:


POSIX threads default to having the PTHREAD_INHERIT_SCHED
attribute. There's a problem though: it all fubars if the parent
thread is an eCos thread, not a POSIX one.


<hugo>
Don't do that then.
</hugo>

Well in the first instance certainly :-).


Seriously, the POSIX system was not designed to be mixed with
non-POSIX threads in this way. [snip[

Yep, and that's what I've been telling people. But I'm just thinking of helping people avoid making the error! At the very worst I'll document it. It's a moderately obscure failure mode.


Unfortunately the child thread can't tell what the parent is (and
relying on magic numbers or somesuch is Bad). I notice from the man
pages that Linux/glibc defaults to PTHREAD_EXPLICIT_SCHED. Any reason
we shouldn't do the same?

PTHREAD_EXPLICIT_SCHED implies that the schedpolicy and schedparam have been supplied explicitly. This is clearly not the case when we are talking about defaults.

In Linux the default values of schedpolicy and schedparam are
SCHED_OTHER and zero. This equates to a non-niced timsharing thread,
the default for all Linux processes. We have no such concept in eCos,
and just choosing an arbitrary policy and priority is almost certainly
the wrong thing to do.

What, like we do for main() that other threads inherit from? ;-P


Seriously, it seems no worse than that.

I ask because it it's a not insignificant change in semantics.

I would oppose such a change. A better change might be to fail pthread_create() if it is called from a non-POSIX thread without explicit scheduling attributes.

Ah, but how do we reliably tell what the parent is. If we know for sure it's non-POSIX we can just DTRT anyway so that it doesn't try and inherit. Any method of detecting whether or not it's a POSIX thread seems to ultimately rely on a magic number happening to be valid. The only other route is exhaustive searches of thread lists, obviously a non-starter.


Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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