[fpc-pascal] Where is IsMultiThreaded set under Linux?

[Graeme Geldenhuys]

On 8 October 2010 15:32, Andrew Brunner wrote:
> This seems like a discussion of semantics more than anything.  In an
> application thread if you say WAITFOR something then the app cannot
> process messages b/c the execution is put on hold until WAITFOR
> returns.  This is normal behaviour, IMO.
>
> So if this is just an exercise, I really don't see a problem.  What's
> the issue you're trying to solve?

OK, my example just just that... to highlight the problem of using
TThread.WaitFor.

My real usage is in tiOPF. tiOPF has various cached logging classes,
all done via threads. It's cached
because we don't want to slow down the main application while output
is written to a file or log window. So logging is written out to disk (or
a GUI screen) when the thread gets time slices.  Now say you instantly
generated 1 million log entries (so the thread has a huge backlog, and
because you have a slow hard drive...in the case of logging to a
file), and now you quit your application.
The application needs to wait for the logging threads to complete
before it can terminate.
This is where the problem comes in. As soon as I call
SomeThread.WaitFor, the application is frozen - it never gets to
terminate completely because WaitFor never returns. All our apps are
database GUI apps, but strangely enough, it is not only limited to GUI
apps. The unit testing framework of tiOPF is Text or GUI. I run the
daily build under our Linux server and it is non-gui based. The test
runs never complete/terminate because there are five logging threads
frozen which never returned from WaitFor. So I had to implement that
boolean field and a while loop hack, instead of calling WaitFor [when
I use FPC and Linux].


-- 
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net:8080/fpgui/