Re: PTHREAD_INHERIT_SCHED

[Jonathan Larmour <jifl at eCosCentric dot com>]

Nick Garnett wrote:
> Jonathan Larmour <jifl@eCosCentric.com> writes:
>
>
> > 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.
>
>
> What I don't want to happen is for people to get used to the idea of
> mixing eCos and POSIX stuff too much. I would much rather such things
> failed gracefully that have to go to the effort of making it work, and
> keeping it working regardless of what we might need to do in the future.

Sure - an explicit assert would be better than at present for example. 
Just not the status quo :). I'm not particularly bothered in making it 
work - just whatever it takes to make sure people avoid the problem!

> > 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.
>
>
> I would have thought that having a NULL pthread_info pointer was
> sufficient indication that the thread was non-POSIX. What more do you
> think is needed?

I was going to say because the it involves indirecting via the info in the 
per-thread data slot, but of course the slots should be initialized to 
zero in all valid threads, so yes you're right.

I'll add an assert then.

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