|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: No-threads patch revisited
Quoting Maurizio Monge (email@example.com): > Hello, > > You (dok) told me that my no-thread patch was not safe because it is not safe > because it is not safe not listening all the time... > > I am thinking about the following rework of the patch: > if messages for a certain program are sent, a bool var referred to the program > pid is set somewhere in shm and tested at the beginning of every interface > function, and if it is set /dev/fusion is processed. That sounds reasonable, but I would like that as a configure option. Maybe we could add "--disable-fusion-thread". The next step would be to add "--disable-threads" which would also remove linkage against libpthread (no mutexes etc. used) for single threaded applications. > -bad, +good (IMHO): > (-=) no message is received if no directfb function is called (but should > safe, isn't it?) The only problem would be the queue in the kernel. I didn't add a limitation yet, because there are just a few messages at all. Most messages are mouse movements. But what to do if the maximum number of messages is reached? > (-) need to add some code everywhere, maybe a branch could be created for > testing... That would be good. We didn't use branches, yet. > (+=) should not slow down things (a var is tested), and removing an > intermediate thread should make the app a bit more resposive (not very > important). Right. > (++) (and i think this could be quite important) at the beginning of every > directfb function you are sure that all events have been processed (a in some > poits a lock could be set to be sure things are not changing since last > notification), ie we should not hope that the messaging thread is always fast > enough to process critical messages :-) That's currently an issue. I made a hot fix that checks if the shared memory file should have been remapped when a SIGSEGV arrives. If a remap cured the fault the program continues ;-P > any other concern? My only concern is code readability and maintainance. There should be max. a single line added to each interface method. > I have a further improvement and bugfix of the last optimization i posted, > could i have cvs write access (i mean to commit some other small > improvements, not to implement changes like what planning above... )? > > if ok, i'd like to have "monx" as nick, or else some other patches are > coming :-) I will suggest that. But for now patches are ok. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-dev" as subject.