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

Reply via email to