Re: [fpc-devel]TThread hara-kiri

2003-11-13 Thread KJK::Hyperion
At 18.15 13/11/2003, you wrote: And 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_sets

Re: [fpc-devel]Some idea of joint units

2003-11-13 Thread Peter Vreman
>> 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

Re: [fpc-devel]TThread hara-kiri

2003-11-13 Thread Peter Vreman
>> 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. > Ofcourse. That is the whole point of making tthread.inc dependent on SysThrds. Th

Re: [fpc-devel]TThread hara-kiri

2003-11-13 Thread Johannes Berg
> 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-com

Re: [fpc-devel]Some idea of joint units

2003-11-13 Thread Johannes Berg
> 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 acc

Re: [fpc-devel]Some idea of joint units

2003-11-13 Thread Peter Vreman
> >> 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 a

Re: [fpc-devel]Some idea of joint units

2003-11-13 Thread Exebook.com
> 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 un

Re: [fpc-devel]Some idea of joint units

2003-11-13 Thread Marco van de Voort
> > 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 immens

Re: [fpc-devel]Some idea of joint units

2003-11-13 Thread Exebook.com
> 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 ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]TThread hara-kiri

2003-11-13 Thread Marco van de Voort
> > 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 > o

Re: [fpc-devel]TThread hara-kiri

2003-11-13 Thread Johannes Berg
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

Re: [fpc-devel]Some idea of joint units

2003-11-13 Thread Marco van de Voort
> > 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< - - - -

[fpc-devel]Some idea of joint units

2003-11-13 Thread Yakov Sudeikin
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< - - - -

Re: [fpc-devel]TThread hara-kiri

2003-11-13 Thread Peter Vreman
>> 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". > > When I compile it with 1.9.1 I get the same effect - program is > immediately killed (the message "Killed