Maybe I'm affected by bad luck, but almost all applications I happen to develop must run under Linux and must deal with data coming at unpredictable times from some external connection. It may be a network connection, a serial device, a special device, but always coming in an unpredictable way.

Possible scenarios are:

1) Freezing the GUI for an undetermined amount of time, waiting for data

2) Loosing the data arriving while the GUI is doing something else.

3) Both sometimes freezing the GUI and sometimes loosing the data.

4) Take advantage of multithreading, have separate threads which monitor and process incoming data, and then neatly synchronize with GUI.

For some obscure reasons, neither I nor my customers find the first three options acceptable, so I usually I'm forced to select the fourth one.

I boldly start a new Application, begin to populate my window with required gadgets, write the thread code, push F9, and my Application crashes. Then I revise my code, looking for all obvious errors, and after a painful search, I discover that I had either forgot to add -dUseCThreads to program options, or , even worse, that I had simply misspelled it.

From the posts I see from time to time in this list, it appears that I'm not the only one to suffer this sort of problem.

Now I know that it's been debated if multithreading should be enabled by default in Unix environment, and the conclusion has been that it should not. I can't say that I found the arguments against multithreading very convincing, but I don't want to reopen a closed discussion.

What I ask is: would it be so hard to provide the choice in the "New" dialog? Something like Single Thread Application and Multi Thread Application? The choice could be either hidden or flash an error for the platforms where multithreading is not supported, would be a no-op for Windows, but would make life easier to the rest of us. I could provide a patch if pointed to the right area of code to deal with. IDE things remain a big mystery to me.

Giuliano

More appropriate place might be in Project -> Options somewhere?

Bart

[...] I boldly start a new Application, begin to populate my window with required gadgets, write the thread code, push F9, and my Application crashes.

Here I get an exception:
Semaphore init failed (possibly too many concurrent threads)

Maybe this error message should be extended under unix with '... or you forgot to use the cthreads unit'

Then I revise my code, looking for all obvious errors, and after a painful search, I discover that I had either forgot to add -dUseCThreads to program options, or , even worse, that I had simply misspelled it.

The -dUseCThreads is for multithreaded packages.

A program can simply remove the {$IFDEF UseCThreads} in the lpr:

  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}

AFAIK the real pain is to find the cause of the strange/misleading error messages. The remedy itself is pretty simple (a flag or a tiny code change).

A new project type is only added if it changes several things not one flag or one tiny change.

A project has many flags and programmers have different opinions what flags should be asked on creation.
Maybe some common options can be shown in the "New dialog".

Mattias

Il 28/04/2012 10:21, Mattias Gaertner ha scritto:

The problem arises from TThread being in fpc rtl, which is of course unaware of Lazarus needs.
In Customdrawn, where I experimented a separate thread for timer events, it's been quite easy to add a clear error message if threading is not enabled:

constructor TCDX11TimerThread.Create(CreateSuspended: Boolean;
   const StackSize: SizeUInt);
var
   thisTM: TThreadManager;
begin
   GetThreadManager(thisTM);
   if not Assigned(thisTM.InitManager) then begin
     Raise Exception.Create
     ('You must define UseCThread (-dUseCThreads in Project Options->  Compiler Options) in order to run this program!');
     end;
   inherited Create (CreateSuspended);
   [..]

A LazThread class defined in LCL which wraps TThread and performs appropriate checks could be a solution?

Giuliano

This is not Lazarus specific.
A console application gets the same error.

The above check can be used to improve the semaphore message of the RTL.

Mattias

Il 28/04/2012 19:26, Mattias Gaertner ha scritto:

On Sat, 28 Apr 2012 11:43:31 +0200 Giuliano Colla wrote:

[..]

IOW you mean that the issue can/should be submitted to the fpc list?

Giuliano

Yes

Mattias