[directfb-dev] Re: No-threads patch revisited

[Denis Oliver Kropp <dok@directfb.org>]

Quoting Maurizio Monge (monge@sns.it):
> 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 ecartis@directfb.org with 
"unsubscribe directfb-dev" as subject.