mutex locking time is... *heh* around 26000 microseconds...  Longer than
poll()....  Go figure.

And you can't do interthread communication without -some- form of locking,
be it kernel or userspace.  (socket I/O locking is handled in the kernel)

Anyways, for future reference : streams are faster than messages.
Unless you have a -really- speedy lock-aquisition system...

How does this apply to GGI?  Easy.  Don't do lock-aquisition in
commands/etc unless you -have- to.  Regardless of how thread-friendly you
want it.

Graphics programming isn't particularily multithread friendly anyways.
You don't really want to have multiple command-streams to most videocards
and even worse, mixing rendering with accels can be fatal on some.

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.

Sorry, just playing with massively threaded proggies finding delays :)

G'day, eh? :)
        - Teunis

incidentally, mandrake 6.0 + upgraded kernel + compiler

Reply via email to