[Lazarus] PostMessage return value
mschnell at lumino.de
Thu Sep 18 10:08:34 CEST 2014
On 09/17/2014 04:51 PM, Xiangrong Fang wrote:
> 2014-09-17 16:09 GMT+08:00 Michael Schnell <mschnell at lumino.de
> <mailto:mschnell at lumino.de>>:
> Here you are.
> It is strange that it works on one computer but does not work (or
> partially work) on another -- causing SIGSEGV. Both running same
> environment - Ubuntu 14.04 x86_64 fpc 2.6.4 laz1.2.4.
That in fact is strange.
Of course here (Linux x86_32, newest svn version of fpc and Lazarus) it
does work, otherwise I would not have posted it.
Did you try the unmodified project ?
> I don't understand how the critical section works.
TCriticalSection is a straight forward semaphore. (->
Of course there are several kinds of semaphores out there:
- binary and counting: TCriticalSection is binary
- blocking or not blocking when a Thread/Task tries to take it while
it already holds it: TCriticalSection does not block
- allowing or disallowing a Thread/Task to free it even though it is
helt by another Thread/Task: TCriticalSection disallows this.
> I try to write a test program, which does the following:
> The main thread create a predefined number of threads, which start
> running on creation. The thread's wait for a critical section
> variable, when acquired, try to crack a given integer, see if it is
> prime number or not, report back to main thread about the result and
> get the next number to crack from main thread. The main thread output
> crack result of every thread in a memo box.
Are you sure that only the main thread does anything related to the GUI
? This is strictly forbidden for worker threads and results in SIGSEGV.
This is why TThreadPool offers events OnReady events that are run in the
main thread. ("synchronized").
> I simply don't know how to coordinate the threads. And got many
> strange errors like
> Semaphore init failed (maybe too many running threads)?
I never saw such an error. Anyway, I suppose you will do multithreading
just for sake of performance. Here running more threads than
CPUs/Hardware Threads does not make sense, as it will slow down the
calculation due to unnecessary time slice related task switches which
result in local cache misses (Linux tries to keep a thread on the same
CPU if possible, but this is only possible when there are not much more
active threads than CPUs). So there will never be "too many" threads.
In any case start with simple stuff (e.g. using my example and replacing
the "Tasks" with first simple and then more complex "Execute" procedures.
> something wrong in raise.c, laz asked me if I want to locate myself,
I have no idea what "raise.c" is supposed to be.
> May I send you my source, or you can write a demo for me? Thanks a lot!
I already did provide you with a demo. I can enhance this for you if you
have a certain request.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lazarus