On Fri, 28 Jan 2000, Rodolphe Ortalo wrote:
> teunis wrote:
> > mutex locking time is... *heh* around 26000 microseconds... Longer than
> > poll().... Go figure.
>
> So much ? Well, it must be implemented via a system call then...
> Well, with threads managed by the kernel it is not so astonishing,
> but you can surely do much better if you only want to lock
> in-memory data structures...
>
> Which library do you use for threads/mutexes, linuxthread ? POSIX ?
linuxthreads -> ie threading that comes with glibc-2.1
> Oh. by the way, while I'm thinking, how did you do your benchmark ?
> An empty lock/unlock I guess ? Not by two threads on a uniprocessor
> I hope (this environment implies a scheduling so... here is your
> implicit system call....)
gettimeofday(). Yeah, I know, there's better ways. If anyone can tell me
- please! I'm guessing at this at every step. All I know now is with
-all- the I/O handling removed from the movie handler except for movie
decoding the thing finally plays fluidly on my computer. Most of the
time.
I think my code's pretty poor actually for movie playing but I don't know
how to do it better.
> > Now on the flip side, it'd be very handy to have a libGGIthreads library
> > or something to give one a threaded interface to -all- of GGI.
>
> Hmmm. With additional delays, I don't know if it would be worth
> the work (especially as everyone would try to use for hype and then
> go back complaining about the performance)...
>
> Nevertheless, your application is very interesting with
> respect to this issue of real-graphic-world MT programming !
Thanks :)
[code at http://www.geocities.com/winterlion... its the 'ggiplay' proggy
:]
It plays linux quicktimes. And mp3's *giggle*. And mpeg-2 multimedia
though the renderer's broken. Gonna write my own soon.
G'day, eh? :)
- Teunis
