CVSROOT: /cvs/directfb
Module name: DirectFB
Changes by: dok 20030808 20:10:16
Modified files:
src/core : coredefs.h thread.c
Log message:
Added DFB_ASSUME which is like DFB_ASSERT, but doesn't send SIGTRAP and
has "(?)" instead of "(!)" at the beginning of the debug message.
Failing assumptions are not fatal. They can be used to unveil unusual
behaviour, e.g. dfb_thread_join() called while already joining/joined.
Optimized creation of new threads by not waiting for pthread_create completion
in spawned threads. Also don't enter the main routine after initialization if
another is already joining. This is useful if DirectFB is initialized, but
deinitialized shortly after. In this case the fusion_read_loop() is not entered.
On a P3 800E with only fbdev (systems) and matrox (gfxdrivers) installed I did
"while true; do dfb_init_deinit &> /dev/null; done"
where 'dfb_init_deinit' (slave) just calls DirectFBInit/Create/Release.
This results in about 170 iterations per second and looks like 5.8 ms for a
complete init/deinit for slaves, but bash is consuming a lot of CPU, too.
Debug messages show that a complete DirectFBInit/Create/Release (as a slave)
takes 3-4 ms ;)
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-cvs" as subject.
