This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: PTHREAD_INHERIT_SCHED
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Nick Garnett <nickg at ecoscentric dot com>
- Cc: eCos developers <ecos-devel at sources dot redhat dot com>
- Date: Fri, 13 Jun 2003 14:55:40 +0100
- Subject: Re: PTHREAD_INHERIT_SCHED
- References: <3EE94B75.3070509@eCosCentric.com> <m3adcm9y9r.fsf@miso.calivar.com>
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