Razvan Adrian Bogdan ha scritto:
On Dec 12, 2007 12:13 PM, Marc Weustink <[EMAIL PROTECTED]> wrote:
The LCL won't be threadsafe, the overhead isn't worth the gain.
Do you think it's an overhead to use the internal locking mechanism from GTK ?
I tend to think it's a very light mechanism that you don't even feel
in singlethreaded applications, having a threadsafe LCL means one can
freely code without any headaches from synchronization making the code
look nicer and dramatically cutting developing time, but i do think
it's a lot of code. I tend to think the LCLs overhead comes from using
classes too much in the lower level API abstraction part.
The problem isn't in the lower level. The problem is at the highest
level. TApplication creates a queue of messages, and then processes them
in the most efficient way as far as images updating is concerned,
without any concern for threads.
In Delphi the synchronize method is an inefficient and buggy kludge
because the thread support wasn't taken into account in the original design.
I don't know of Lazarus, because I didn't study it, but I'm afraid that
it resents of the Delphi compatibility issue, which sometimes means
emulate Delphi bugs, or deficiencies.
However making Lazarus LCL thread safe can be a lot of work, but would
be an enormous bonus which would enable to use it in all fields where a
real efficient thread support is needed and currently you have no RAD tools.
All applications where GUI actions (such as displaying information,
activating dialogs, etc.) aren't originated by user input devices, but
rather from threads listening for external events, such as IP
connections, would benefit from this feature. They're a lot, and they're
increasing.
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
