Re: Thoughts from FreeBSD on the upcoming GNOME 2.2

On Thu, 14 Nov 2002, Thomas Vander Stichele wrote:

> Hi,
> > GThread limitations? Can you be more specific as to what you mean? I hope
> > you aren't relying on a GThread being the same a pthread, as that is in
> > general not true.
> No,  we're not.  We know that the thread lib being used underneath it is 
> platform-dependant, which is exactly why we want to find some way to use 
> GThreads and then still do what we try to do.

oh - good 8-)

> The limitation we need to specifically find a workaround for is the fact 
> that GThreads allocate a stack for the thread themselves, because we have 
> one cothread implementation that does the allocation itself.
> Ie, we currently would need to hand GThreads a pre-allocated stack.

this should be a relatively straightforward api extension, with the
caution that not all thread environments would (potentialy) support
creation of threads with user allocated stacks.

> Now, it might also be possible to find some way to not need to do that, 
> but that's the thing we're working on currently - which is why we welcome 
> anyone who has some experience and knowledge about these issues to take a 
> look and suggest alternatives we could use.
> > > Our main problem is - we don't have any testers on platforms other than 
> > > ppc and x86.  We've been actively looking for them on other platforms, but 
> > > people seem somehow not inclined to test on other platforms.  We're not 
> > > quite sure how to solve that issue ;) Any ideas here are welcome.
> > 
> > Well, the present architecture is not exactly one that people are bound to
> > run to to embrace.
> Which means what, exactly ?
> > So the easiest way to get people to like to test it is
> > to timetravel back and make changes... 8-)
> I'm not sure what you mean by this, but it doesn't sound very constructive 
> ;) If you mean to say, "there is something about GStreamer that makes me 
> not want to test it or help people in testing it" then tell me what it is 
> so we can work on that and get somewhere we want to be instead of being 
> somewhere we both don't want to be.

Developers in general - with very very few exceptions don't want to go
anywhere near even normal problems with threads - they are considerably
less likely to go anywhere near problems involving an additional level of
threads built on top of normal threads. This is hardly a controversial
statement or one that hasn't been known for ages. 

> Thanks,
> Thomas
>  -- 
> The Dave/Dina Project : future TV today ! -
> <-*- thomas (dot) apestaart (dot) org -*->
> God how I hate myself for
> still wanting her
> <-*- thomas  (at) apestaart (dot) org -*->
> URGent, the best radio on the Internet - 24/7 ! -


	There are voices in the street,
	And the sound of running feet,
	And they whisper the word --

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]