Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2015-12

alternatives for "cwstring" and "cthreads"

8 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

http://www.freepascal.org/docs-html/rtl/cwstring/
http://www.freepascal.org/docs-html/rtl/cthreads/

Both the "cwstring and "cthreads" units (as per the documentation) says that it links to the C library of unix systems.

Does this make your programs more dependent on a specific version of the C library? Or can you run a current unix program (say compiled on the latest Ubuntu Linux) on say a 10 year old Linux? [lets assume it is a console or daemon application, not GUI]

Are there any drawbacks in letting your program link to such a C library?

Are there alternatives to those units that don't link to such a C library, but still allows your unix programs to use threading and unicode text (new FPC codepage-aware String)?

Just curious. ;-)

Regards,
- Graeme -

My public PGP key: http://tinyurl.com/graeme-pgp

Jonas Maebe
to Graeme Geldenhuys

Graeme Geldenhuys wrote on Fri, 11 Dec 2015:

Show quoted text 7 lines
Both the "cwstring and "cthreads" units (as per the documentation) says that it links to the C library of unix systems. Does this make your programs more dependent on a specific version of the C library? Or can you run a current unix program (say compiled on the latest Ubuntu Linux) on say a 10 year old Linux? [lets assume it is a console or daemon application, not GUI]

Most likely yes. E.g., a dummy program containing just this:

***
uses
   cthreads, cwstring;
begin
end.
***

works fine when compiled on
"Linux xxx 2.6.18-194.11.4.el5 #1 SMP Tue Sep 21 06:46:41 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux" against GLibC 2.5 and when run on "Linux YYY 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux" with EGLibC 2.19. Vice verse works fine too.

Are there any drawbacks in letting your program link to such a C library?

The biggest drawback is that you need to have the libraries available when cross-compiling from another platform.

Are there alternatives to those units that don't link to such a C library, but still allows your unix programs to use threading and unicode text (new FPC codepage-aware String)?

If you don't mind your program's size blowing up massively due to having to include all of the unicode transcoding tables, you can use the cpall unit in combination with the fpwidestring unit instead of cwstring (or you can ship the tables as external files, but that won't reduce their size).

No one has implemented a thread manager in Pascal, afaik. It would also be very OS-specific if someone did: it would be Linux-specific, and depending on which features of the kernel it uses, possibly less backward compatible than the cthreads unit.

Jonas

Graeme Geldenhuys
to Jonas Maebe

Many thanks Jonas for all that information. It is very useful to know.

Maybe the documentation for cwstrings should include a link to fpwidestring unit and vice-verse. I didn't know about the fpwidestring unit.

As for the thread manager being very OS-specific. Well FPC being a compiler that as very CPU and OS specific functionality well abstracted... such a thread manager should be just another abstraction layer. ;-) I'm not suggesting the FPC team implement it, just saying that on a high level it seems quite doable.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp
Jonas Maebe
to Graeme Geldenhuys
Graeme Geldenhuys wrote 5 lines
As for the thread manager being very OS-specific. Well FPC being a compiler that as very CPU and OS specific functionality well abstracted... such a thread manager should be just another abstraction layer. ;-) I'm not suggesting the FPC team implement it, just saying that on a high level it seems quite doable.

Of course it's doable, and that's exactly what libpthread does (quite well, quite portably and quite backward compatibly).

Jonas

Sven Barth
to Graeme Geldenhuys: Many thanks Jonas for all that information. It is very useful to know. Maybe the…
Graeme Geldenhuys wrote 10 lines
Many thanks Jonas for all that information. It is very useful to know. Maybe the documentation for cwstrings should include a link to fpwidestring unit and vice-verse. I didn't know about the fpwidestring unit. As for the thread manager being very OS-specific. Well FPC being a compiler that as very CPU and OS specific functionality well abstracted... such a thread manager should be just another abstraction layer. ;-) I'm not suggesting the FPC team implement it, just saying that on a high level it seems quite doable.

Our thread manager is already such an abstraction. It's just that for Unix platforms only cthreads currently exists.

At least on Linux one could implement one using the clone() system call, but that would need to be implemented for each platform and additional features like mutexes, etc. would need to be implemented as well (it's not as if I didn't have that idea already ;) ). The main reason it doesn't exist yet is that no one implemented it... if one would we would probably add it...

Regards,
Sven

Mark Morgan Lloyd
to Jonas Maebe: Graeme Geldenhuys wrote on Fri, 11 Dec 2015: Most likely yes. E.g., a dummy program…
Jonas Maebe wrote 24 lines
Graeme Geldenhuys wrote on Fri, 11 Dec 2015: > Both the "cwstring and "cthreads" units (as per the documentation) says > that it links to the C library of unix systems. > > Does this make your programs more dependent on a specific version of the > C library? Or can you run a current unix program (say compiled on the > latest Ubuntu Linux) on say a 10 year old Linux? [lets assume it is a > console or daemon application, not GUI] Most likely yes. E.g., a dummy program containing just this: *** uses cthreads, cwstring; begin end. *** works fine when compiled on "Linux xxx 2.6.18-194.11.4.el5 #1 SMP Tue Sep 21 06:46:41 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux" against GLibC 2.5 and when run on "Linux YYY 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux" with EGLibC 2.19. Vice verse works fine too.

I agree for what it's worth, there are areas that are far less stable.

Working from memory, the one area where one might need to be careful is if looking at thread IDs to determine whether a piece of code is executing in the context of the main thread, since the semantics changed at some point and the changes happened at different kernel/library versions on different architectures.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Michael Schnell
to Jonas Maebe: Of course it's doable, and that's exactly what libpthread does (quite well, quite…
Jonas Maebe wrote
Of course it's doable, and that's exactly what libpthread does (quite well, quite portably and quite backward compatibly).

The Libpthread dynamic library is great in that in Linux it uses what the OS and the Arch provides: it automatically uses Futex, whenever available and with that can greatly speed up certain kind of applications. Here Libpthread does not simple provide OS API calls, but (needs to) provide user space code that is executed (called) by the application.

But to allow this, the application needs to dynamically link to the Libpthread implementation that is provided by the system (i.e corresponding to the Kernel version) the application is installed on.This might be a problem for applications that shrive to be self-contained.

Is there LibPThread for Windows, at all ? Does it provide something that might be considered Futex functionality ?

-Michael

Sven Barth
to Michael Schnell
"Michael Schnell" wrote
Is there LibPThread for Windows, at all ? Does it provide something that

might be considered Futex functionality ?

I'be seem some pthreads libraries for Windows, but honestly if one targets Windows one shouldn't use some compatibility library and instead use the native threads directly (like we do).

Regards,
Sven