Hi guys,
thank you for the tons of information about the multithreading system in
FPC.
In one of my mails I've mentioned a project (beepfp) which uses external
threads
from the vortex dll.
There is a hint to the instability problem we are discussing here:
{ FPC specific thread create function to replace Vortex's thread create.
This is required because FPC doesn't work when C libraries create their own
threads}
The solution they found here was to implement a callback in the dll that
passes
a FPC function to create threads to use inside the dll.
The code for unix to create the thread is:
...
//Start thread
BeginThread(@C2P_Translator, ThreadData, TThreadID(thread_def^) );
if TThreadID(thread_def) > 0 then
//Don't free memory here, it is done in the thread function
Result := axl_true
else
begin
//Free memory
dispose(ThreadData);
Result := axl_false;
end;
...
initialization
// Set pascal specific thread creators
vortex_thread_set_create(@fpc_vortex_thread_create);
vortex_thread_set_destroy(@fpc_vortex_thread_destroy);
...
this seems to solve the problem and that is what I am testing now too.
If the dll calls the fpc callbacks
now it will be in the context of it's own thread.
The question is now: Why does this work ?
If BeginThread initializes the stack which needs to be done to make
external threads work it will work with this example
too. Did the creator of this code find a regular solution for this
problem or did he just work around the problem by making
external threads internal ?
Maik
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
