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
