cthreads

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

cthreads

Juha Manninen
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, not at run-time.
Could 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Michael Van Canneyt


On Fri, 25 Jul 2014, Juha Manninen wrote:

> 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, not at run-time.
> Could it be fixed somehow?

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Mark Morgan Lloyd-5
Michael Van Canneyt wrote:

> On Fri, 25 Jul 2014, Juha Manninen wrote:
>
>> 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, not at run-time.
>> Could it be fixed somehow?
>
> No, because there is no way to detect that threads are actually used in
> the program.

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

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 :-)

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Michael Van Canneyt


On Fri, 25 Jul 2014, Mark Morgan Lloyd wrote:

> Michael Van Canneyt wrote:
>> On Fri, 25 Jul 2014, Juha Manninen wrote:
>>
>>> 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, not at run-time.
>>> Could it be fixed somehow?
>>
>> No, because there is no way to detect that threads are actually used in the
>> program.
>
>> I will add a remark in the classes unit TThread class documentation, to
>> make it even more obvious.
>
> 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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Fabio Luis Girardi
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 <[hidden email]>:


On Fri, 25 Jul 2014, Mark Morgan Lloyd wrote:

Michael Van Canneyt wrote:
On Fri, 25 Jul 2014, Juha Manninen wrote:

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, not at run-time.
Could it be fixed somehow?

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

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

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.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



--
The best regards,

Fabio Luis Girardi
PascalSCADA Project
http://sourceforge.net/projects/pascalscada
http://www.pascalscada.com

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Ewald-2
On 07/25/2014 03:04 PM, 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.


--
Ewald

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Fabio Luis Girardi


2014-07-25 10:10 GMT-03:00 Ewald <[hidden email]>:
On 07/25/2014 03:04 PM, 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.


--
Ewald




--
The best regards,

Fabio Luis Girardi
PascalSCADA Project
http://sourceforge.net/projects/pascalscada
http://www.pascalscada.com

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Sven Barth-2
In reply to this post by Ewald-2

Am 25.07.2014 15:11 schrieb "Ewald" <[hidden email]>:
>
> On 07/25/2014 03:04 PM, 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.

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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Marco van de Voort
In reply to this post by Fabio Luis Girardi
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.
 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

leledumbo
Administrator
> 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?
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Sven Barth-2
On 26.07.2014 19:50, leledumbo wrote:
>> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Mark Morgan Lloyd-5
Sven Barth wrote:

> On 26.07.2014 19:50, leledumbo wrote:
>>> 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...

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?

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Marco van de Voort
In reply to this post by leledumbo
In our previous episode, leledumbo said:
> > 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?

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.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Marco van de Voort
In reply to this post by Mark Morgan Lloyd-5
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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Sven Barth-2
In reply to this post by Mark Morgan Lloyd-5
On 27.07.2014 11:39, Mark Morgan Lloyd wrote:

> Sven Barth wrote:
>> On 26.07.2014 19:50, leledumbo wrote:
>>>> 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...
>
> 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.

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

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Henry Vermaak
On Sun, Jul 27, 2014 at 02:39:58PM +0200, Sven Barth wrote:

> On 27.07.2014 11:39, Mark Morgan Lloyd wrote:
> >Sven Barth wrote:
> >>On 26.07.2014 19:50, leledumbo wrote:
> >>>>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...
> >
> >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.
>
> That's not true. E.g. the Qt libraries happily create threads for various
> background stuffs.

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: cthreads

Sven Barth-2
On 27.07.2014 17:01, Henry Vermaak wrote:

> On Sun, Jul 27, 2014 at 02:39:58PM +0200, Sven Barth wrote:
>> On 27.07.2014 11:39, Mark Morgan Lloyd wrote:
>>> Sven Barth wrote:
>>>> On 26.07.2014 19:50, leledumbo wrote:
>>>>>> 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...
>>>
>>> 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.
>>
>> That's not true. E.g. the Qt libraries happily create threads for various
>> background stuffs.
>
> 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.

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal