[Lazarus] DocView and FPC documentation release

[Graeme Geldenhuys]

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