Hi,
Does the example program threads.pp (doc/examples/fcl/threads.pp) work for anybody under Linux?
It aborts for me as soon as the first thread is created, printing "Killed".
Regards,
Pedro

Mailing lists / fpc-devel / 2003-11
20 messages · 10 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Hi,
Does the example program threads.pp (doc/examples/fcl/threads.pp) work for anybody under Linux?
It aborts for me as soon as the first thread is created, printing "Killed".
Regards,
Pedro
When I compile it with 1.9.1 I get the same effect - program is immediately killed (the message "Killed" is printed by bash, it indicates that the program was killed by SIGKILL). When I compile it with 1.0.10 (with fcl distributed with 1.0.10) things are even worse.
This is a question to FPC developers - is this example supposed to work (i.e. is TThread class now officially implemented in fcl or is it just a stub that may work but don't have to) ?
Michalis
TThread needs to be rewritten to use the functions from SysThrds unit.
Guten morgen,
The same idea that I sent to borland bug/feature website years ago and want to share with greatly respected FPC community.
Let's call it "reuse unit", wich can save a lot of time and space for developers and is really easy to understand. For instance you create a unit:
- 8< - - - - - - - - - - begin unit - - - - - - -
Unit VCL;
Reuse Classes, Forms, Controls, Dialogs;
- 8< - - - - - - - - - - end unit - - - - - - -Then in your app you only type
use VCL;And that's it. This will be just the same as using all of the units, this is kinda cool, ain't it? Especially with the smartlinking. In C++ you can get the same results with the preprocessor, but preprocessors suck you know.
Thanks,
Yakov
What would be the use ?
Hi,
TThread needs to be rewritten to use the functions from SysThrds unit.
Interestingly I just noticed the same thing as the original writer, and also identified the problems.
Only problem was that I was unable to send mail, those mails are still stuck on my computer. In any case, I'm offering to take a look at the TThread rewrite.
johannes
Please no more clone() :-)
What would be the use ?
What would be the use ?
the use would be to simplify the development and distribution for those who program for fun this is not the point of course
> What would be the use ? the use would be to simplify the development and distribution for those who program for fun this is not the point of course
IMHO it works both ways. It can remove the need to specify some units, so if B is updated, A is up to date, but it can also cause an immense amount of units to be included that it is not intended.
So (again IMHO) the disadvantages outstrip the disadvantages by far.
So (again IMHO) the disadvantages outstrip the disadvantages by far.
Ouch, not exactly so my dear. What you mean is the redundant code has the chance to get into the executable. But first there is smartlinking, second there could be "smartuniting" and third, most libraries anyway use all the units, declared from each other. For instance I downloaded jpeg.pas and it uses 100 other units from the package, but to utilize this library in my program I had to add at least 5 units! jpeg.pas, jpegsave.pas, jpegload.pas, jpegbase.pas and even some others. Those _all_ are anyway used in jpeg.pas, so the code is anyway in the executable, but it is not convenient to add 5 units everywhere I need jpeg graphics. Other example is tollbar library I downloaded a some time ago, the main unit links to 50 other units, and to use the library properly you have to declare from 3 to 10 of them in your uses clause, inconvenient. Examples are many! Just to lazy to count, and almost always all the units are explicitly declared in the main unit, so the code always gets into the executable anyway. Another simple example is the RSA crypto lib, it uses bigint.pas. If you want to crypt something - you will always need bigint.pas just to declare the key/signature variables, this would be really convenient if the rsa.pas had the "reuse bigint" line somewhere in the interface part - and no extra byte will go to the exe anyways. Hope this makes sense. If no, just believe me, I program since 80-ies and this partucular feature of pascal was coming into my head every now and again, so it is kinde "tested by time". I would not recommend to discuss it if the results would be rather negative and the idea was not well thought. I do not want to spare your busy time of course, not a minute without a good reason for the entire community.
Also back to first and second of my points - "smartuniting" (smartlinking in terms of units rather than procedures) is relativly simple feature, that can propagate into the compiler along with the "reuse" keyword. So that only those units from the "Reuse" list are actually demanded from the main program or unit would link. And smartlinking (in terms of procedures) is already there, it is not enabled by default for some reason though. By the way I would like to know why it is not the default behaivior, I suspect it is due to it's buggy nature, but maybe one day it can be declared "stable". From your barely entusiastic reaction I suggest that this feature is unlikely to ever get on board, but it can at least deserve a small discussion among those who think pascal.
Thanks
Yakov
<snip some big story>
Smartlinking and smart unit including is a requirement for this.
It can maybe added as extension when support for packages is added. In the unit clause the name of a package can be reference and all units in the package will be implicitly included. When the unit/program is compiled the unused units will be removed.
But extensions like this are certainly 2.0+ features. So don't expect anything soon.
Peter
But first there is smartlinking, second there could be "smartuniting"
Impossible, you can't have the compiler remove a unit just because nothing from it is used, the unit could contain an object that only registers itself with a factory on initialization, thus nothing from the unit is ever accessed directly, but removing the unit would seriously impact the program.
johannes
Please no more clone() :-)
BeginThread uses pthread_create :-)
Btw -- shouldn't tthread.inc then be moved to inc/ instead of {sys}/? It would probably be platform-independent itself if using BeginThread.
And another thing to discuss is Suspend()/Resume() which isn't really possible on posix-compliant systems, but I will refrain from saying more right now until I get a chance to post the thoughts I already wrote (but are still stuck on my computer) until I get a chance to send my mails out tomorrow.
johannes
Impossible, you can't have the compiler remove a unit just because nothing from it is…
The compiler knows if the unit contains initialization/finalization. See the unused unit hint already supported (try 1.9.x because 1.0.x is broken with this support).
But initialization can also have negativ sides. Let say the RTL is included in a single package/unit. Then all programs depend on the graph unit (and under linux svgalib.so) because it has an initialization section. How to solve that?
BeginThread uses pthread_create :-) Btw -- shouldn't tthread.inc then be moved to inc/…
Ofcourse. That is the whole point of making tthread.inc dependent on SysThrds. The SysThrds unit is the platform independent layer for all basic multithreading operations. In the end tthread.inc can be moved to the objpas/classes directory together with all the other .inc files of the Classes unit.
BeginThread uses pthread_create :-) Btw -- shouldn't tthread.inc then be moved to inc/…
you wroteAnd another thing to discuss is Suspend()/Resume() which isn't really possible on posix-compliant systems,
you can send a signal to the target thread (pthread_kill), handled by waiting indefinitely on a semaphore created by BeginThread and associated (pthread_setspecific) to the new thread
How about this?
- 8< - - - - - - - - <vcl.inc> - - - - - - -
Classes, Forms, Controls, Dialogs
- 8< - - - - - - - - </vcl.inc> - - - - - - -
Then in your app you only type
uses {$i vcl.inc};__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
How about this? uses {$i vcl.inc};
This would be the usage of preprocessor, which will work of course, but as the whole progressive humanity seeks the way to avoid preprocessors, it might be not wise to go like this.
Yakov
the whole progressive humanity seeks the way to avoid preprocessors
find /home/jeff/cvs/fpc/ \
-name '*.inc' -or -name '*.pas' -or -name '*.pp' \ -exec grep '{\$' '{}' ';' | wc -l
( found 11385 directives )
find /usr/include/ /usr/local/include/ \
-name '*.h' -exec grep '^\#[ \t]*[a-z]' '{}' ';' | wc -l
( found 134711 directives )
If the whole progressive humanity is seeking a way to avoid preprocessors, they certainly aren't doing a very good job!
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
The same idea that I sent to borland bug/feature website years ago and want to share with…
03-11-13 13.01, skrev Yakov Sudeikin följande:
In the "Mac World", this "uses propagation" has existed a long time. It means that all units in the uses-clause (in the interface part) of a unit is exported. You can turn on/off this feature on a project basis, if you want to stay compatible with old code. In fact this feature is often used instead of $include.
Olle