Re: [gst-devel] Re: RFC: GNOME 2.0 Multimedia strategy
- From: Erik Walthinsen <omega temple-baptist com>
- To: Alan Cox <alan redhat com>
- Cc: Christian Schaller <Uraeus linuxrising org>, <gnome-hackers gnome org>, <gnome-sound-list gnome org>, <gstreamer-devel lists sourceforge net>
- Subject: Re: [gst-devel] Re: RFC: GNOME 2.0 Multimedia strategy
- Date: Sat, 19 May 2001 16:10:19 -0700 (PDT)
On Sat, 19 May 2001, Alan Cox wrote:
> Values of 100 times faster for linux clone over pthreads create are not
> unreasonable.
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.
The best choice for a replacement seems to be GNU Pth, except that it's
not set up to deal with pthreads afaict (I haven't tested this). The
cothread stacks must live in the pthread stack space, else pthreads gets
confused about stack pointers or somesuch (result: SEGV). IBM's working
on an N:M variant of GNU Pth, which was just released BETA-1 a few days
ago. This should do the trick, but it's not ready yet, and I dunno what
the final timeline is (though they're *ahead* of schedule, afaict).
Fundamentally, though, GStreamer is set up to allow any scheduling
mechanism you want, as long as it's somehow capable of fulfilling the
basic requirements. There's a now a single entity that's responsible for
determining how to run the elements, with the current implementation using
cothreads. Any other mechanism that can provide separate contexts will
work, with various performance penalties. The slides on gstreamer.net
explain the plugin styles and why the require some sort of context.
This scheduling mechanism isn't pluggable yet only because I haven't set
up loading and such for it. It's set up with a ~vtable and such so it's
completely replacable. Just need to build a new one that uses pthreads,
or GNU Pth, or clone() or whatever. Will have to probably create new
Thread and Queue elements to match though, for obvious reasons.
> If gstreamer is going to be accepting remote connections has anyone given it
> a formal auditing ? Until network code is audited I think we should not be
> committing to it
As of now there are only a couple network plugins: rtpsend, icecastsend.
Both of these use existing libraries to do their work. But in any case,
GStreamer itself has nothing to do with networking, it's all the various
plugin's job. That should significantly limit the amount of code that
needs to be auditted, I think.
Erik Walthinsen <omega temple-baptist com> - System Administrator
__
/ \ GStreamer - The only way to stream!
| | M E G A ***** http://gstreamer.net/ *****
_\ /_
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]