I was asked why a threaded application compiles on Linux without "uses cthreads" but it does not work.
cthreads must _always_ be added to uses section.
I had no answer to that. IMO such errors should be trapped at compile-time, it be fixed somehow?
Many people experience the same run-time error about too many concurrent threads. They must search the net and ask questions while (I guess) the problem could be solved by forcing a compilation error.

Juha

No, because there is no way to detect that threads are actually used in the program.

The TThread class is a class like any other, with no special treatment. It is in the classes unit.

The fact that it is there does not mean it is actually used. That goes for a lot of code.

You don't even need to use the TThread class;
you can perfectly program threads with just the threadmanager.

In retrospect, Borland made an error declaring tthread in the classes unit. It should have been put in a separate unit. That would have made detection easier.

Many people experience the same run-time error about too many concurrent threads. They must search the net and ask questions while (I guess) the problem could be solved by forcing a compilation error.

Or - for once in their life - people could read the documentation.

http://www.freepascal.org/docs-html/prog/progse43.html

It is remarked TWICE that you must include the cthreads unit.

I will add a remark in the classes unit TThread class documentation, to make it even more obvious.

Michael.

Is there scope for improving the error message?

Is there a scenario in which a program that sometimes uses threads (e.g. if it realises it's being asked to do a big job which can be parallelised) could start without giving the error message? This would make the situation more serious, since it would require that the programmer did some /real/ testing before shipping his code :-)

Not sure what you mean.

The error only appears if you call a function that relies on the threading manager, never at the start of the program. It's slightly more complicated than this, but it boils down to that.

So the fact that the program started doesn't mean there won't be an error further down the line. But that is IMHO no different from many other programming errors, such as trying to save preferences in a file in a directory that doesn't exist. You should always test all cases.

Michael.

The same question that I posted on bugtracker:

Linux, BSD, Unix, has another threaddriver than cthreads? If no, why not make cthreads unit the default threaddriver for Unix?

2014-07-25 7:33 GMT-03:00 Michael Van Canneyt :

Fabio Luis Girardi wrote

The same question that I posted on bugtracker: Linux, BSD, Unix, has another threaddriver than cthreads? If no, why not make cthreads unit the default threaddriver for Unix?

I read somewhere some time ago that the main reason for this was that FPC has no dependency to libc under normal circumstances. Making cthreads the default thread manager would thus add a dependency to libc.

2014-07-25 10:10 GMT-03:00 Ewald :

This is correct. It's the same reason for the widestring manager provided by cwstrings unit. Though 2.7.1 now has a Pascal only widestring manager as well. :)

Regards,
Sven

In our previous episode, Fabio Luis Girardi said:

The same question that I posted on bugtracker: Linux, BSD, Unix, has another threaddriver than cthreads?

No.

If no, why not make cthreads unit the default threaddriver for Unix?

Because then all apps are linked to it, also the ones that don't need threads. Same for clocale and cwstrings.

Because then all apps are linked to it, also the ones that don't need

threads. Same for clocale and cwstrings.

If the widestring manager could be made by ourselves, is it possible for thread manager as well?

Principiall yes, but the problem here would be external code that the program links to. E.g. Wine did something like this some time ago (before they switched to pthreads) and needed to simulate some structures so that libc switches to multithreaded mode... So if we have Pascal only code (like the compiler) this would work without big problems (if someone implements it of course ;) ), but if you have 3rd party code not written in FPC then problems might arise...

Regards,
Sven

On the other hand, if somebody's linking in "alien" code then he should make himself aware of aware of the prerequisites, particularly since the threads are more likely to be in the main program (i.e. stuff that he's written) than in the library he's pulling in.

Going back to something less labour intensive, would it be possible to have s directive which has the effect that if a procedure isn't eliminated by smartlinking then the linker should warn if a specific library hasn't been linked?

In our previous episode, leledumbo said:

You could make an own threadmanager in theory. I have some doubts about the usability and practicality though. If it ever emerges I think it will remain for specific cases, not a general replacement.

The difference with the unicode manager is that you per definition need OS support for the general threadmanager case. With unicode you have the choice to go via the OS (and be light on bulky tables in every binary) or implement it yourself based on the liberally licensed Unicode consortium's tables.

In our previous episode, Mark Morgan Lloyd said:

Going back to something less labour intensive, would it be possible to have s directive which has the effect that if a procedure isn't eliminated by smartlinking then the linker should warn if a specific library hasn't been linked?

ELF binaries generally don't require to associate a symbol with a library name to link, like on Windows.

That's not true. E.g. the Qt libraries happily create threads for various background stuffs.

Regards,
Sven

Ha, I had a library that started a thread and it took me ages to figure out why my pascal program was crashing on callbacks from external threads. I had to start a dummy thread right at the start of the program, even though I included cthreads. Not a good experience all in all.

Henry

Yes, the FPC RTL is normally running in singlethreaded mode and at least one FPC thread (besides the main one) needs to be started to switch it in multithreaded mode. I thought that we had some improvements there at least in 2.7.1, but I'd need to check that again.

Regards,
Sven