[gst-devel] Re: RFC: GNOME 2.0 Multimedia strategy (fwd)
omega at temple-baptist.com
Sun May 20 02:35:00 CEST 2001
Oops, for some reason it doesn't like keeping gst-devel on the cc: list.
---------- Forwarded message ----------
Date: Sat, 19 May 2001 17:34:27 -0700 (PDT)
From: Erik Walthinsen <omega at temple-baptist.com>
To: Alan Cox <alan at redhat.com>
Cc: Christian Schaller <Uraeus at linuxrising.org>, gnome-hackers at gnome.org,
gnome-sound-list at gnome.org
Subject: Re: [gst-devel] Re: RFC: GNOME 2.0 Multimedia strategy
On Sat, 19 May 2001, Alan Cox wrote:
> > GStreamer isn't using clone(), but cothreads with setjmp/longjmp. The
> > code came from OGI, where I was working when I started this project. It's
> > been reasonably portable so far, but other OS's will likely frag that.
> I doubt many will. KA9Q NOS was ported to everything from DOS to Unix through
> AmigaOS and other systems without problems and was based on setjmp hackery
Hmm, interesting. The cothreads code I have has to construct a base stack
for each cothread. If you aren't using pthreads, this can just be a
malloc(). The main issue is that the current implementation requires two
assembly bits to do it. The first sets the stack pointer, the second
jumps into the main() of that cothread. Now, it's very likely that the
jmp can be done as a call (it is on x86, and that has the 'advantage' of
letting gdb show the cothread switch history, as well as providing a soft
landing if the cothread stub falls out), saving one hassle.
The issue is then still the bit about setting up the base of the new
cothread stack frame. The GNU Pth code has lots of C-only tricks that
in various combinations work for the vast majority of architectures, and
that could probably be easily used instead (about 450 lines, iirc).
However, there's the question of how that'd interact with pthreads, since
the cothread stacks must live inside the pthread's stack region in order
for pthreads not to have a cow (not a CoW, unfortunately <g>).
IBM's working on modifying GNU Pth to support multiple cothreads in
multiple pthreads (N:M), but they're not ready, and they seem to be having
significant architecture-specific problems. Dunno when we might be able
to switch to that.
So, I'm not totally convinced it's as portable as you say it might be,
because as Sopwith and sander pointed out, there are things like stack
direction and machines where pthreads aren't LWPs (read: freebsd) that
would make hash out of that.
Any suggestions on the best way to proceed?
Erik Walthinsen <omega at temple-baptist.com> - System Administrator
/ \ GStreamer - The only way to stream!
| | M E G A ***** http://gstreamer.net/ *****
More information about the gstreamer-devel