Re: [gst-devel] Re: RFC: GNOME 2.0 Multimedia strategy

[Daniel Veillard <veillard redhat com>]

On Sat, May 19, 2001 at 08:15:24PM -0400, 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

  I have used this approach quite extensively in other projects. The main
problem (it was the case of example on AIX) is if longjmp() checks the
stack pointer value to prevent hacking and using a separate stack (the
solution was 20 lines of assembly, I may have archived them).
  Other than that even finding the entry in the setjmp block where the
stack need to be saved when creating such a co thread can be written in
a portable way.

  The problem seems to me that the current pthread does a 1-1 matching
between the kernel thread and the user thread. More advanced threads libraries
(like the one available on Mach) take great care of avoiding this problem
and remapping N users threads on n kernel threads for better use of system
resources and faster context switching when switching between threads within
the same task/process.

  The whole debate sounds to me that the current pthread implementation ain't
good enough. I would rather see it fixed than build the co-thread routines
within the multimedia libray...

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers