On Thursday 13 December 2007 01.28, Giuliano Colla wrote: [...] > The screen is a shared resource, so it must be granted exclusive > access. If one thinks of one main thread which besides doing its job > receives messages from all the worker threads, creates a clean queue of > what needs to be done (sorting out what's visible and what not, what > must be drawn and what not, etc.), and passes that to a graphic thread > which is the only one which has access to the display, then you have a > real multithread GUI, which could fill a void in what's currently > available. It could be a challenging project, don't you think? > It just requires a not too large GUI system already existing (such as > fpGui, not Lazarus which is too big to play with) and some enthusiasm > (and also a lot of time, but for my company it could be important, so > some resources could be found). > Don't forget MSEide+MSEgui: http://sourceforge.net/projects/mseide-msegui MSEgui has several possibilities to synchronize worker threads with the main GUI thread.
First there is application.lock/unlok which works on a mutex. The main eventloop acquires the mutex on start of a new round of the main eventloop and releases it after it gets idle. Secondly there is application.synchronize which runs a callback in a try/finally block with application.lock/unlock. Thirdly there is application.postevent in order to send messages to MSEgui components. The posted events are feed into the main event queue and are delivered to the component in context of the main thread. application.postevent is thread safe and does not block. tmsecomponent.postcomponentevent and asyncevent can be used for convenience, tmseform tmsedatamodule have onevent and onasyncevent where the messages can be handled in context of the main thread. Fourthly there is FPC synchronize with the problem that checksynchronize is called once in onidle of then main event loop. One can call application.wakeupguithread to enable processing but there is a race condition. Worth to mention is teventthread with its own message queue. The graphic subsystem has its own locking mechanism so it is possible to draw onto off screen canvas (pixmap or printer) from worker threads. Martin _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives