Hello,

Is it safe to use DebugLn from thread other than main?

2011/3/29 cobines :

Hello, Is it safe to use DebugLn from thread other than main?

You can use DbgOutThreadLog
ref.: http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial

best regards
tomek

Hello, Is it safe to use DebugLn from thread other than main?

No.

Mattias

OK, thanks both for answers. DbgOutThreadLog function seems useful, but I need to write to console so I'll use DebugLn via Synchronize.

Mattias Gaertner wrote

> Is it safe to use DebugLn from thread other than main? No.

(Me again, but I could not resist: )

I suppose It would be very easy to make a thread save version of DebugLn if TApplication.QueueAsyncCall would be fixed in GTK (and all other WidgetTypes)

-Michael

cobines wrote

OK, thanks both for answers. DbgOutThreadLog function seems useful, but I need to write to console so I'll use DebugLn via Synchronize.

If you take a look at the tiOPF v2 available from SourceForge.net, it has tiLog, tiLogToGUI, tiLogToConsole, tiLogToEvent, tiLogToFile, tiLogToDebugServer etc...

No matter the final output, the Log(..) lines are all the same. There are even convenience log functions for outputting various variable types in a neatly formatter manner. You can even enable logging at runtime via a command line parameter, you can enable multiple output targets (eg: file and gui output). The logging is all thread safe, and some output targets have built-in cache so as not to slow down your application when you log a huge amount of data.

The tiOPF log units are quit independent, so your application doesn't need to be based on tiOPF classes just to use the logging facility.

http://www.tiopf.com
http://www.sourceforge.net/projects/tiopf/

Regards,
- Graeme -

It seems it is enough to protect the call to DebugLn with a critical section:

var
  cs: syncobjs.TCriticalSection;
procedure DebugLnThreadSafe(const s: String);
begin
  cs.Acquire;
  try
    DebugLn(s);
  finally
    cs.Release;
  end;
end;

I would not recommend using it, because this component hijacks the command-line options.

Michael.

I would not recommend using it, because this component hijacks the command-line options.

No it doesn't! Why do you say that?

Yes there is a convenience unit that automatically registers the various log output targets (the unit is located in GUI/tiLogReg.pas), but that unit is purely optional because it pulls in GUI dependencies (log to gui). That unit is not included by default in any tiOPF package (*.lpk) files.

In all our project we manually register and integrate the tiLogXXX units with our custom command line handling code. We have never used the tiLogReg unit.

Regards,
- Graeme -

cobines wrote

I'll use DebugLn via Synchronize.

Synchronize is not a good option for DebugLn, as (1) you need to pass parameters and (2) it will stall the thread for an unforeseeable amount of time. Application.QueuAsyncCall has been provided for exactly that purpose by some thoughtful person log ago, but alas,....

-Michael

On 03/30/2011 09:16 AM, Graeme Geldenhuys wrote:e.

If you take a look at the tiOPF v2 ...

Do you happen ton know how this makes sure that it works in a thread-safe way ?

(With our Delphi projects we do thread safe logging via "PostMessage", but with Lazarus this is a moving target, depending on the Widget Type right now.)

-Michael

Because last time I checked, it was so. I even reported it to you at the time. If I recall correctly, the -l option was used to decide where to write log files.

Admittedly, this is a long time ago.
Maybe the implementation has been changed in the meantime.

If so, please disregard my remark.

Michael.

cobines wrote

It seems it is enough to protect the call to DebugLn with a critical section:

IMHO, not a good idea at all, as DebugLn, being a debug feature is supposed to be as non-intrusive as possible. And a critical section might stall the thread for an unforeseeable amount of time and kill the behavior that made you decide to put the code in question into a thread.

-Michael

Admittedly, this is a long time ago. Maybe the implementation has been changed in the meantime.

That must have been a good few years ago (I think back in tiOPF v1 days). I just double checked tiOPF v2. None of the tiLogXXX units do any automatic log registration or command line processing. It's all left up to the developer how they want to process command line parameters, what log output targets to register, or what log severity levels should be set as default.

Regards,
- Graeme -

Michael Schnell wrote

Do you happen ton know how this makes sure that it works in a thread-safe way ?

The details are in the Core/tiLog.pas unit, and is not too complicated. You are welcome to take a look at that code.

http://tiopf.sourceforge.net/SourceCodeRepository.shtml

(With our Delphi projects we do thread safe logging via "PostMessage",

tiOPF doesn't use Windows API's for logging. It is a totally Object Pascal implementation and fully cross-platform.

Regards,
- Graeme -