Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
Al 15/10/10 22:31, En/na Vinzent Höfler ha escrit: - FreeOnTerminate should be gone, (meaning no way to actively call TThread.Destroy from another thread, a thread gets destroyed automatically when it leaves its execute method) I don't agree, the creator of the thread should be able to see what's happening to it (i.e. keeping a reference to the thread without risking a SIGSEV because the thread has terminated). Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On Sat, 16 Oct 2010, Luca Olivetti wrote: Al 15/10/10 22:31, En/na Vinzent Höfler ha escrit: - FreeOnTerminate should be gone, (meaning no way to actively call TThread.Destroy from another thread, a thread gets destroyed automatically when it leaves its execute method) I don't agree, the creator of the thread should be able to see what's happening to it (i.e. keeping a reference to the thread without risking a SIGSEV because the thread has terminated). That's what the OnTerminate() event is for, that should definitely remain. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] WinCE / Win32 compilation
I am still compiling delphi code and do now compile for both win32 and winCE. WinCE works (but executable untested), while win32 complains a few places: 1) Whenever I compile single = min(single,single) I have to add math.min or the win32 compiler complains and expects longints instead. Is there a difference between the RTL in the two versions? I have not been able to setup a small example, showing this. Unfortunately. Max function has the same issue. 2) I use TCriticalsection, but get this message: Error: Unknown record field identifer Create. I get similar error when calling enter, leave or free methods. This one stops me at the moment. TIA Uffe Kousgaard ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WinCE / Win32 compilation
On 16 Oct 2010, at 12:11, Uffe Kousgaard wrote: I am still compiling delphi code and do now compile for both win32 and winCE. WinCE works (but executable untested), while win32 complains a few places: 1) Whenever I compile single = min(single,single) I have to add math.min or the win32 compiler complains and expects longints instead. Is there a difference between the RTL in the two versions? Compile with -vh to see which declaration the compiler finds when the compilation fails. 2) I use TCriticalsection, but get this message: Error: Unknown record field identifer Create. I get similar error when calling enter, leave or free methods. TCriticicalSection is not a class, it's a Win API struct. You have to use Windows.InitCriticalSection and friends to work with it. There's also TRTLCriticalSection, which works with System.InitCriticalSection and friends. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: WinCE / Win32 compilation
Jonas Maebe jonas.ma...@elis.ugent.be wrote in message news:6ef537cb-d266-4034-8c96-8286158ac...@elis.ugent.be... 1) Whenever I compile single = min(single,single) I have to add math.min or the win32 compiler complains and expects longints instead. Is there a difference between the RTL in the two versions? Compile with -vh to see which declaration the compiler finds when the compilation fails. Max(LongInt,LongInt): LongInt TCriticalSection is not a class, it's a Win API struct. It is a class in D7, SyncObjs.pas. And understood by the WinCE compiler, at least it seems so. Even if it just maps to the WinAPI, it is still a class. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: WinCE / Win32 compilation
On 16.10.2010 12:35, Uffe Kousgaard wrote: Jonas Maebejonas.ma...@elis.ugent.be wrote in message news:6ef537cb-d266-4034-8c96-8286158ac...@elis.ugent.be... 1) Whenever I compile single = min(single,single) I have to add math.min or the win32 compiler complains and expects longints instead. Is there a difference between the RTL in the two versions? Compile with -vh to see which declaration the compiler finds when the compilation fails. Max(LongInt,LongInt): LongInt TCriticalSection is not a class, it's a Win API struct. It is a class in D7, SyncObjs.pas. And understood by the WinCE compiler, at least it seems so. Even if it just maps to the WinAPI, it is still a class. TCriticalSection is a WinAPI struct if you include the unit Windows. If you include the unit SyncObjs it's a Object Pascal class that uses FPC's cross platform TRTLCriticalSection. The problem is if you include both units it depends on the order of the unit which type wins. E.g. uses Windows, SyncObjs; var cs: TCriticalSection; // will be SyncObjs.TCriticalSection (a class) but uses SyncObjs, Windows; var cs: TCriticalSection; // will be Windows.TCriticalSection (a record) This is the same in Delphi by the way. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
- FreeOnTerminate should be gone, (meaning no way to actively call TThread.Destroy from another thread, a thread gets destroyed automatically when it leaves its execute method) (IIRC FreeOnTerminate was even set to False by the default constructor, so you had the choice of either using the default or introducing a race condition by setting it after the inherited Create - which starts the execute.) This problem has been solved with http://bugs.freepascal.org/view.php?id=16884 Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal i don't agree with always FreeOnTerminate. I have many prgramms that want to know the last status of the thread before they free it. But i think also the bug report you are linking to, shouldn't be a fpc bug. It is more a programmer bug. As programmer i have to know at which time i call the create methode of my TThread. So the correct programming would be: constructor TAThread.SomeCreate(aSuspended : boolean); begin [... do my things here ...] inherited create(aSuspended); end; or constructor TAThread.SomeCreate(aSuspended : boolean); begin inherited create(True); [... do my things here ...] if not aSuspended then Resume; end; I don't think fpc should slow down the thread creating, just to resolve problems of not good thread programming of the fpc users. When someone starts to programm threads, he has to know what he is doing. cu all Beni ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On 16 Oct 2010, at 13:57, Benedikt Schindler wrote: - FreeOnTerminate should be gone, (meaning no way to actively call TThread.Destroy from another thread, a thread gets destroyed automatically when it leaves its execute method) (IIRC FreeOnTerminate was even set to False by the default constructor, so you had the choice of either using the default or introducing a race condition by setting it after the inherited Create - which starts the execute.) This problem has been solved with http://bugs.freepascal.org/view.php?id=16884 But i think also the bug report you are linking to, shouldn't be a fpc bug. It is more a programmer bug. As programmer i have to know at which time i call the create methode of my TThread. He cannot. If freeonterminate=true, then even if you call inherited create(false) as the very last statement of your constructor, the thread may already have finished running and freed itself before AfterConstruction is called. The AfterConstruction call will then crash. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Troubles with overloaded operators
Hi together!
I'm currently wrapping V4L2 in an object oriented way and thought that I
could use operator overloading to convert flag ordinals to Pascal sets.
My operator compiled without problems, but when I tried to use it I got
a type error.
So I reduced my problem to a single test unit:
begin
program opoverload;
{$mode objfpc}
type
TTest = (
test1,
test2,
test3
);
TTests = set of TTest;
operator := (aRight: LongWord) aLeft: TTests;
begin
Result := [];
if (aRight = 0) and (aRight 21) then
Include(Result, test1);
if (aRight = 21) and (aRight = 42) then
Include(Result, test2);
if (aRight = 0) and (aRight = 42) then
Include(Result, test3);
end;
var
i: LongWord;
t: TTests;
begin
i := 21;
// t := i;
end.
end
Compiling it as is succeeds without problems, but enabling the commented
assignment to t results in the following output:
fpc opoverload.pasfpc opoverload.pas
Free Pascal Compiler version 2.4.0 [2010/01/01] for i386
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for i386
Compiling opoverload.pas
opoverload.pas(29,8) Error: Incompatible types: got LongWord expected
TTests
opoverload.pas(31) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /home/sven/.bin/ppc386 returned an error exitcode (normal if you
did not specify a source file to be compiled)
Is this a bug (I'm using 2.4.0, but I've tested it with a 2.5.1 from end
of August as well)? Or is it not possible to use such an overload (which
would be a pity...)?
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Re: WinCE / Win32 compilation
Sven Barth pascaldra...@googlemail.com wrote in message TCriticalSection is a WinAPI struct if you include the unit Windows. OK, that explains. In Delphi the WinAPI struct is called TRTLCriticalSection. So, no name clashing. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On Sat, Oct 16, 2010 at 7:04 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: He cannot. If freeonterminate=true, then even if you call inherited create(false) as the very last statement of your constructor, the thread may already have finished running and freed itself before AfterConstruction is called. The AfterConstruction call will then crash. Right. I think that it would have been totally acceptable due to the nature of threads especially on differing os(es) to not have AfterConstruction because of this very issue. The fact that threads can zip through their execute event and self terminate before the AfterConstruction is even called is definitely an issue that can only be solved with synchronization of some sort. Threads are a special case where these objects themselves represent a kernel process with its own distinct timeline. Logically, performance cannot be a priority when requiring synchronization of differing timelines. But for small projects where Delphi offers TThread with these features, it is good for FPC to accommodate Delphi source. There is always going to be a demographic who will never need performance and performance is not much of an issue for projects with 1000 threads to the observer. IMO, it would be better to leverage the present performance condition to muster support for a high performance thread component set. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On Sat, 16 Oct 2010, Andrew Brunner wrote: On Sat, Oct 16, 2010 at 7:04 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: He cannot. If freeonterminate=true, then even if you call inherited create(false) as the very last statement of your constructor, the thread may already have finished running and freed itself before AfterConstruction is called. The AfterConstruction call will then crash. Right. I think that it would have been totally acceptable due to the nature of threads especially on differing os(es) to not have AfterConstruction because of this very issue. The fact that threads can zip through their execute event and self terminate before the AfterConstruction is even called is definitely an issue that can only be solved with synchronization of some sort. Threads are a special case where these objects themselves represent a kernel process with its own distinct timeline. Logically, performance cannot be a priority when requiring synchronization of differing timelines. But for small projects where Delphi offers TThread with these features, it is good for FPC to accommodate Delphi source. There is always going to be a demographic who will never need performance and performance is not much of an issue for projects with 1000 threads to the observer. IMO, it would be better to leverage the present performance condition to muster support for a high performance thread component set. How about creating a) A native TThreadManager record in system unit for unices. b) Create a alternative thread class (TFPThread, TRTLThread, TFastThread or whatever) that uses the TThreadManager record to create 'Fast' threads, which would not be encumbered by the Delphi heritage of TThread. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC for High Performance Computing (HPC) Components with Application API
On Fri, Oct 15, 2010 at 5:10 PM, Henry Vermaak henry.verm...@gmail.com wrote: I've told you before: NPTL is part of the glibc sources. Download the latest glibc sources and look in the nptl directory. The latest glibc release is 2.11.2. FPC source to cThreads unit and the thread manager associated with threading under linux presently calls a pthreads.so object. When I did my research I thought I was correct in making an assumption that pthreads.so would require a pthreads project with it's own make file ;-) That is the latest and greatest pthreads project which is now associated with glibc. pthreads is the standard, not the implementation. The current most widely used implementation is called NPTL. Your link points to LinuxThreads (judging by the name, I didn't download): pthreads is not the standard. pthreads.so is the implementation of POSIX thread specification to be precise :-) Ok. You mentioned NPTL. What can you tell me about that? Is that the project that makes pthreads? I'm looking to get the latest and greatest source of posix threads so I draw upon that code and perhaps even come up with a native version for FPC. Any help would be greatly appreciated. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On 16.10.2010 15:36, Michael Van Canneyt wrote: How about creating a) A native TThreadManager record in system unit for unices. I don't think this can be done for all Unix systems in a generic way, because e.g. on Linux you should use the clone syscall (which is Linux only) while on e.g. Mac OS X you should rely on the c library cause the syscall interface might be changed by Apple (@OS X devs: please correct me if this is wrong). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
In our previous episode, Michael Van Canneyt said: IMO, it would be better to leverage the present performance condition to muster support for a high performance thread component set. How about creating a) A native TThreadManager record in system unit for unices. b) Create a alternative thread class (TFPThread, TRTLThread, TFastThread or whatever) that uses the TThreadManager record to create 'Fast' threads, which would not be encumbered by the Delphi heritage of TThread. If Delphi legacy is of no object, and it is new development, simply design in a threadpool. If construct/destruction is slow, then don't. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
Jonas Maebe wrote: He cannot. If freeonterminate=true, then even if you call inherited create(false) as the very last statement of your constructor, the thread may already have finished running and freed itself before AfterConstruction is called. The AfterConstruction call will then crash. Will it crash if it is empty as in TObject? procedure TObject.AfterConstruction; begin end; It does not in MSEgui tmsethread, up to now at least. ;-) Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
In our previous episode, Sven Barth said: How about creating a) A native TThreadManager record in system unit for unices. I don't think this can be done for all Unix systems in a generic way, because e.g. on Linux you should use the clone syscall (which is Linux only) FreeBSD supports rfork, which has similar functionality (the subset (?) implemented by Clone in the linuxator is implemented by a rfork call Yrying to build on the clone call has been done in 1.0.x times, and I don't have fond memories about it. while on e.g. Mac OS X you should rely on the c library cause the syscall interface might be changed by Apple (@OS X devs: please correct me if this is wrong). First we would have to get rid of this solution in search of a problem attitude. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On 16 Oct 2010, at 15:46, Martin Schreiber wrote: Jonas Maebe wrote: He cannot. If freeonterminate=true, then even if you call inherited create(false) as the very last statement of your constructor, the thread may already have finished running and freed itself before AfterConstruction is called. The AfterConstruction call will then crash. Will it crash if it is empty as in TObject? The contents of AfterConstruction don't matter. If the instance is freed before the constructor had a chance to call AfterConstruction, the self pointer won't be valid anymore in the constructor and hence the call to AfterConstruction may crash. Note that in svn trunk, self can no longer be freed before AfterConstruction has been called because of the fix from http://bugs.freepascal.org/view.php?id=16884. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On 16.10.2010 15:45, Marco van de Voort wrote: In our previous episode, Sven Barth said: How about creating a) A native TThreadManager record in system unit for unices. I don't think this can be done for all Unix systems in a generic way, because e.g. on Linux you should use the clone syscall (which is Linux only) FreeBSD supports rfork, which has similar functionality (the subset (?) implemented by Clone in the linuxator is implemented by a rfork call Yrying to build on the clone call has been done in 1.0.x times, and I don't have fond memories about it. I did a quick check: NPTL and thus the pthreads implementation on current Linux systems use clone as well. I don't know what the trouble were, but if we want a native thread manager on Linux we should try clone again (as well as using rfork on FreeBSD). while on e.g. Mac OS X you should rely on the c library cause the syscall interface might be changed by Apple (@OS X devs: please correct me if this is wrong). First we would have to get rid of this solution in search of a problem attitude. What do you mean by the this solution in search of a problem attitude? I can't follow you currently... :( Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
In our previous episode, Sven Barth said: FreeBSD supports rfork, which has similar functionality (the subset (?) implemented by Clone in the linuxator is implemented by a rfork call Yrying to build on the clone call has been done in 1.0.x times, and I don't have fond memories about it. I did a quick check: NPTL and thus the pthreads implementation on current Linux systems use clone as well. No doubt. I don't know what the trouble were, but if we want a native thread manager on Linux we should try clone again (as well as using rfork on FreeBSD). Well, I still would have to see a good case for a native manager made. But one of the problems with clone was IIRC that it wasn't easily wrapped like other syscalls. It will need to be done in asm per architecture IIRC. while on e.g. Mac OS X you should rely on the c library cause the syscall interface might be changed by Apple (@OS X devs: please correct me if this is wrong). First we would have to get rid of this solution in search of a problem attitude. What do you mean by the this solution in search of a problem attitude? I can't follow you currently... :( People seem to first want to bash pthreads, and discuss own threadmanagers before actually defining what the problem of the current solution is, and why it is absolutely needed to create something new. Like, euh, why simply having a thread pool to workaround slow creation is not a better solution (and as done for decades by vast numbers of programmers) All I have seen is some complaint about slow starting threads by sb who can't even find the proper pthread source, and now we are suddenly making room for a native threadmanager? A bit premature IMHO. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On Sat, 16 Oct 2010 10:45:49 +0200, Luca Olivetti l...@ventoso.org wrote: Al 15/10/10 22:31, En/na Vinzent Höfler ha escrit: - FreeOnTerminate should be gone, (meaning no way to actively call TThread.Destroy from another thread, a thread gets destroyed automatically when it leaves its execute method) I don't agree, the creator of the thread should be able to see what's happening to it (i.e. keeping a reference to the thread without risking a SIGSEV because the thread has terminated). Well, the usual implementation of an externally called Destroy is - first a call to the Terminate method - then a WaitFor() Unfortunately WaitFor maps quite directly to pthread_join() while a self-destruction is done by pthread_exit(). You can NOT call both without triggering undefined behaviour which - beginning with some 2.6 kernel - was a segmentation fault already, and you can not call pthread_join() from the same thread, this would deadlock. There are several solutions to the problem, each one with its own drawbacks. I would like to avoid additional synchronisation requirements as well as introducing new race conditions. With these implementation issues, implementing a race condition free WaitFor is already hard enough, but allowing Destroy to be called externally adds more issues than it can possibly solve. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Re: Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
Jonas Maebe wrote: On 16 Oct 2010, at 15:46, Martin Schreiber wrote: Will it crash if it is empty as in TObject? The contents of AfterConstruction don't matter. If the instance is freed before the constructor had a chance to call AfterConstruction, the self pointer won't be valid anymore in the constructor and hence the call to AfterConstruction may crash. What are the conditions that it crashes if self is not used in AfterConstruction? Is there hidden code beside of AfterConstruction after Create() which uses self? As written before it does not crash in tmsethread which does not inherit from FPC TThread. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Re: Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On 16 Oct 2010, at 17:13, Martin Schreiber wrote: Jonas Maebe wrote: The contents of AfterConstruction don't matter. If the instance is freed before the constructor had a chance to call AfterConstruction, the self pointer won't be valid anymore in the constructor and hence the call to AfterConstruction may crash. What are the conditions that it crashes if self is not used in AfterConstruction? Is there hidden code beside of AfterConstruction after Create() which uses self? AfterConstruction is called from within Create, after all user code in the constructor has been executed (and if no exceptions occurred). And the call to AfterConstruction uses self, because AfterConstruction is a virtual method (so you have to load self.vtable[afterconstruction_index]). As written before it does not crash in tmsethread which does not inherit from FPC TThread. You're just getting lucky in your tests. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On 16.10.2010 16:47, Marco van de Voort wrote: In our previous episode, Sven Barth said: FreeBSD supports rfork, which has similar functionality (the subset (?) implemented by Clone in the linuxator is implemented by a rfork call Yrying to build on the clone call has been done in 1.0.x times, and I don't have fond memories about it. I did a quick check: NPTL and thus the pthreads implementation on current Linux systems use clone as well. No doubt. I don't know what the trouble were, but if we want a native thread manager on Linux we should try clone again (as well as using rfork on FreeBSD). Well, I still would have to see a good case for a native manager made. But one of the problems with clone was IIRC that it wasn't easily wrapped like other syscalls. It will need to be done in asm per architecture IIRC. Right... I forgot about that... while on e.g. Mac OS X you should rely on the c library cause the syscall interface might be changed by Apple (@OS X devs: please correct me if this is wrong). First we would have to get rid of this solution in search of a problem attitude. What do you mean by the this solution in search of a problem attitude? I can't follow you currently... :( People seem to first want to bash pthreads, and discuss own threadmanagers before actually defining what the problem of the current solution is, and why it is absolutely needed to create something new. One of the problem seems to be that we need to link an external library. While FPC allows us to do so much things with Pascal code only, we need to add a dependency when we want to use threading. Note: On Windows this feels different, as here kernel32.dll is THE interface to the OS, while libc/pthread aren't on Unix systems (there the OS interface consists of the syscalls to the kernel). Like, euh, why simply having a thread pool to workaround slow creation is not a better solution (and as done for decades by vast numbers of programmers) Maybe we should provide a generic thread pool system in the FCL? Then some FPC users might realize that they don't really need a faster thread creation. All I have seen is some complaint about slow starting threads by sb who can't even find the proper pthread source, and now we are suddenly making room for a native threadmanager? Isn't a native threadmanager for Linux on the wishlist of FPC users for quite some time now? :) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
Al 16/10/10 16:57, En/na Vinzent Höfler ha escrit: Well, the usual implementation of an externally called Destroy is - first a call to the Terminate method - then a WaitFor() Nope, I avoid the WaitFor. I usually do a while not FFinished do CheckSynchronize(100); (where FFinished is set when Execute ends). Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Re: Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On Sat, 16 Oct 2010 17:12:51 +0200, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 16 Oct 2010, at 17:13, Martin Schreiber wrote: As written before it does not crash in tmsethread which does not inherit from FPC TThread. You're just getting lucky in your tests. Either that, or the object validity checks are off. IIRC, the problem only occurred with range checks on, otherwise the access to the invalid VMT doesn't (necessarily) cause a crash. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Re: WinCE / Win32 compilation
On 16 Oct 2010, at 14:23, Uffe Kousgaard u...@routeware.dk wrote: Sven Barth pascaldra...@googlemail.com wrote in message TCriticalSection is a WinAPI struct if you include the unit Windows. Appart from unit ordering (which is a shaky way of reliably resolving things), you could always qualify the name with the unit prefix too: var cs: SyncObjs.TCriticalSection; This would universally work across Delphi and FPC and unit order would not matter. Sent from my iPhone___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On Sat, 16 Oct 2010 17:42:03 +0200, Luca Olivetti l...@ventoso.org wrote: Al 16/10/10 16:57, En/na Vinzent Höfler ha escrit: Well, the usual implementation of an externally called Destroy is - first a call to the Terminate method - then a WaitFor() Nope, I avoid the WaitFor. Nice for you, but I'd rather avoid polling solutions. I usually do a while not FFinished do CheckSynchronize(100); Check again. You can't even access FFinished from a foreign thread. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
Al 16/10/10 17:42, En/na Luca Olivetti ha escrit:
Al 16/10/10 16:57, En/na Vinzent Höfler ha escrit:
Well, the usual implementation of an externally called Destroy is
- first a call to the Terminate method
- then a WaitFor()
Nope, I avoid the WaitFor. I usually do a
while not FFinished do
CheckSynchronize(100);
(where FFinished is set when Execute ends).
Btw, this is what a C++ class (cThread in vdr, simple but nice, even it
it's C++ ;) does
cThread::~cThread()
{
Cancel(); // just in case the derived class didn't call it
free(description);
}
void cThread::Cancel(int WaitSeconds)
{
running = false;
if (active WaitSeconds -1) {
if (WaitSeconds 0) {
for (time_t t0 = time(NULL) + WaitSeconds; time(NULL) t0; ) {
if (!Active())
return;
cCondWait::SleepMs(10);
}
esyslog(ERROR: %s thread %d won't end (waited %d seconds) -
canceling it..., description ? description : , childThreadId,
WaitSeconds);
}
pthread_cancel(childTid);
childTid = 0;
active = false;
}
}
bool cThread::Active(void)
{
if (active) {
//
// Single UNIX Spec v2 says:
//
// The pthread_kill() function is used to request
// that a signal be delivered to the specified thread.
//
// As in kill(), if sig is zero, error checking is
// performed but no signal is actually sent.
//
int err;
if ((err = pthread_kill(childTid, 0)) != 0) {
if (err != ESRCH)
LOG_ERROR;
childTid = 0;
active = running = false;
}
else
return true;
}
return false;
}
You can check the whole class here:
http://projects.vdr-developer.org/projects/vdr/repository/revisions/master/entry/thread.h
http://projects.vdr-developer.org/projects/vdr/repository/revisions/master/entry/thread.c
Bye
--
Luca
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Re: Re: Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
Jonas Maebe wrote: As written before it does not crash in tmsethread which does not inherit from FPC TThread. You're just getting lucky in your tests. Hmm, a miracle for me. I used heaptrace which trashes the memory after free AFAIK? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On Sat, 16 Oct 2010 18:04:59 +0200, Luca Olivetti l...@ventoso.org wrote: I use that only for threads I start at the beginning of the app and terminate at the end, so polling isn't a big issue. Those kind of threads are not a big issue at all. As they are running during the whole application's lifetime, race conditions with concurrently running code are about as improbable as the universe collapsing right now. It's not strictly necessary since the OS will clean up everything afterwards, but I prefer to do things properly. And not call pthread_cancel() like the C++ class you given as example and stop threads in the middle of their work? ;) They don't even bother and create all threads in detached state, so you can not pthread_join() and get an exitcode from them. while not FFinished do CheckSynchronize(100); Check again. You can't even access FFinished from a foreign thread. I can (FFinished is a private member defined by me, and Destroy, being a method of the same class, can access private members). Yes, my mistake. I misinterpreted the lines. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
In our previous episode, Sven Barth said: First we would have to get rid of this solution in search of a problem attitude. What do you mean by the this solution in search of a problem attitude? I can't follow you currently... :( People seem to first want to bash pthreads, and discuss own threadmanagers before actually defining what the problem of the current solution is, and why it is absolutely needed to create something new. One of the problem seems to be that we need to link an external library. While FPC allows us to do so much things with Pascal code only, we need to add a dependency when we want to use threading. Yes. So all your programs don't use any libraries except libc because pthreads? If so, what kind of programs do you make? Note: On Windows this feels different, as here kernel32.dll is THE interface to the OS, while libc/pthread aren't on Unix systems (there the OS interface consists of the syscalls to the kernel). I don't see it that way. I'm perfectly happy to take libc/pthread as system interface. If they actually went to the trouble to make it a decent API, somewhat stable in time, and decoupled from e.g. compiler version changes. THAT is the *nix problem, not the name of the library, be it user32 or libc or libroot. Still, while I agree with the problem, I don't think a native threadlib will change anything in this picture. The amount of pain won't lessen. One only adds yet another factor (libc threads vs pascal threads) to the chaos. The only possible thing is wait till Linux and the Unix world at large comes to its senses. Like, euh, why simply having a thread pool to workaround slow creation is not a better solution (and as done for decades by vast numbers of programmers) Maybe we should provide a generic thread pool system in the FCL? Then some FPC users might realize that they don't really need a faster thread creation. I think all sane contributions are welcomed. One can never fully exclude that somebody might actually come up with both a good Pascal only threading library and a good motivation to actually use it. ( I can imagine some limited uses to really quick initialize CGIs or so) But talking about making room in the FPC implementation before these two conditions are satisfied, just because some people think there is a problem, and a solution for that problem. It will just lead to orphaned attempts and a drain on FPC resources. Just look at the discussion about the current TThread implementation, which afaik stems from the 2003-2004 timeframe (when what is now the 2.x series was finalized in the 1.9 beta series). And that is just library usage. How long do you think it will take to get a native implementation up to snuff for real use, beyond being some minimalists pet project ? Even if I forget for the moment that it is DOA out of principle (since it won't play nice with external libs probably), it would take years. And all the while the forces concentrate on that, the current implementation is on ice, waiting for the glorious new code that will fix everything and will never come. Better invest in dressing up the current implementation, synchronization features (syncobjs, TMonitor, locked queues etc), stuff that is really going to be used. Less glory, more result. All I have seen is some complaint about slow starting threads by sb who can't even find the proper pthread source, and now we are suddenly making room for a native threadmanager? Isn't a native threadmanager for Linux on the wishlist of FPC users for quite some time now? :) Not mine. And yes, there has been a lot of echoing of sentiment, but I never saw a decent problem definition, and what a native solution would actually fix. The native threadlib has been a recurring topic since the 1.0.x implementation was trashed, which surfaces at any possible problem in the current thread implementation (which is blown out of proportion to make a case for start over). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On 16.10.2010 18:30, Marco van de Voort wrote: In our previous episode, Sven Barth said: First we would have to get rid of this solution in search of a problem attitude. What do you mean by the this solution in search of a problem attitude? I can't follow you currently... :( People seem to first want to bash pthreads, and discuss own threadmanagers before actually defining what the problem of the current solution is, and why it is absolutely needed to create something new. One of the problem seems to be that we need to link an external library. While FPC allows us to do so much things with Pascal code only, we need to add a dependency when we want to use threading. Yes. So all your programs don't use any libraries except libc because pthreads? If so, what kind of programs do you make? I didn't say that I personally have this problem; it's just the one problem that I'm really aware of. :) But I even have an example where I don't even use libc, but use threads: a downloader (using lnet). Ok... I've recently switched from lnet and threading to calling wget with TProcess, because it was to unreliable, but I HAD such an application where I'd liked to not have any dependency. ^^ Another application in need of native threading might come in some time, because I have an arm-linux system with uclibc where I not yet know how good and reliable its NPTL implementation is. Note: On Windows this feels different, as here kernel32.dll is THE interface to the OS, while libc/pthread aren't on Unix systems (there the OS interface consists of the syscalls to the kernel). I don't see it that way. I'm perfectly happy to take libc/pthread as system interface. If they actually went to the trouble to make it a decent API, somewhat stable in time, and decoupled from e.g. compiler version changes. THAT is the *nix problem, not the name of the library, be it user32 or libc or libroot. That's somehow that what I meant, but with different words. libc/pthread aren't yet stable enough in my opinion to be seen as OS interface. I'd have no problem with them as well if they'd remain stable... Still, while I agree with the problem, I don't think a native threadlib will change anything in this picture. The amount of pain won't lessen. One only adds yet another factor (libc threads vs pascal threads) to the chaos. Yes, that's the biggest problem... :( The only possible thing is wait till Linux and the Unix world at large comes to its senses. Which might take some time... Like, euh, why simply having a thread pool to workaround slow creation is not a better solution (and as done for decades by vast numbers of programmers) Maybe we should provide a generic thread pool system in the FCL? Then some FPC users might realize that they don't really need a faster thread creation. I think all sane contributions are welcomed. One can never fully exclude that somebody might actually come up with both a good Pascal only threading library and a good motivation to actually use it. ( I can imagine some limited uses to really quick initialize CGIs or so) But talking about making room in the FPC implementation before these two conditions are satisfied, just because some people think there is a problem, and a solution for that problem. Who's talking about making room? I thought the recent discussion was about having an alternative thread class that doesn't have the TThread heritage. And also having the possibility to switch between native threads or pthreads (on platforms of which the kernel provides such threading facilities). I don't see why you'd need to make room in FPC's implementation for them. They'd simply be alternatives. :) It will just lead to orphaned attempts and a drain on FPC resources. Just look at the discussion about the current TThread implementation, which afaik stems from the 2003-2004 timeframe (when what is now the 2.x series was finalized in the 1.9 beta series). And that is just library usage. How long do you think it will take to get a native implementation up to snuff for real use, beyond being some minimalists pet project ? Even if I forget for the moment that it is DOA out of principle (since it won't play nice with external libs probably), it would take years. Regarding orphaned attempts: I know what you're talking about. I always think that I've started something without finishing it when I think about my two FPC pet projects cppclass and nativent. But I still have the hope that I'll continue working on them :) And all the while the forces concentrate on that, the current implementation is on ice, waiting for the glorious new code that will fix everything and will never come. Better invest in dressing up the current implementation, synchronization features (syncobjs, TMonitor, locked queues etc), stuff that is really going to be used. I really, really must do more serious work with threads... Regards, Sven
Re: [fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64
On Sat, 16 Oct 2010, Marco van de Voort wrote: All I have seen is some complaint about slow starting threads by sb who can't even find the proper pthread source, and now we are suddenly making room for a native threadmanager? Isn't a native threadmanager for Linux on the wishlist of FPC users for quite some time now? :) Not mine. And yes, there has been a lot of echoing of sentiment, but I never saw a decent problem definition, and what a native solution would actually fix. It would allow me to write programs that are multithreaded and don't use external libs. And yes, they do exist. Not GUI, but server apps. Now, the only dependency is often libc for the threads. There is a clear target: FPC programs without external libs, capable of multi-threading and thread synchronization, which basically means: - Ability to create threads. - Ability to use mutexes across threads. - Ability to use semaphores. It's not because you don't see the value, that other people don't. So at least, please don't stop them from trying to go somewhere, even if you don't want to go there. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC for High Performance Computing (HPC) Components with Application API
On 16 October 2010 14:37, Andrew Brunner andrew.t.brun...@gmail.com wrote: On Fri, Oct 15, 2010 at 5:10 PM, Henry Vermaak henry.verm...@gmail.com wrote: pthreads is the standard, not the implementation. The current most widely used implementation is called NPTL. Your link points to LinuxThreads (judging by the name, I didn't download): pthreads is not the standard. pthreads.so is the implementation of POSIX thread specification to be precise :-) http://en.wikipedia.org/wiki/POSIX_Threads says: POSIX Threads, or Pthreads, is a POSIX standard for threads. libpthread.so is the name of the library, not the name of the implementation. Ok. You mentioned NPTL. What can you tell me about that? Is that the project that makes pthreads? http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC for High Performance Computing (HPC) Components with Application API
On Sat, Oct 16, 2010 at 2:16 PM, Henry Vermaak henry.verm...@gmail.com wrote: libpthread.so is the name of the library, not the name of the implementation. I updated FPC from SVN and it is pointing to this library now :-). Only problem is someone took some changes I made to remove semaphore on thread creation... If I would have known someone was going to commit those changes I would have taken the time to move FSEM into a block where createsuspended was true this way it wouldn't have event effected others who need that barrier :-) Ok. You mentioned NPTL. What can you tell me about that? Is that the project that makes pthreads? http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library This was interesting There exists a tracing tool for NPTL, called POSIX Thread Trace Tool (PTT). And an Open POSIX Test Suite (OPTS) was written for testing the NPTL library against the POSIX standard. ^^^ Could this possibly be a solution or a lead in to getting GDM-GDB to stop locking up on entry to breakpoint?!? I know debugging threads is nearly impossible under Linux (at least with GDB and Ubuntu) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Problem accessing Class Method with abstraction
I've got a class factory problem I'm trying to resolve and it appears I'm at a point where it's probably better to ask for help. TCoreObjects=class; TCoreObject=Class (TPersistent) protected class procedure VerifyIDs(var Module:TDBMSModule); Virtual; abstract; end; TAdminCore=Class(TCoreObject) protected class procedure VerifiyIDs(var Module:TDBMSModule); override; end; SNIP procedure VerifyIDs(Var Module:TDBMSModule); var iLcv:integer; ItemP:PCoreObjectItem; // Just record storing classname to load and (each core object implment is loaded just not detailed here for simplicity) coGeneric:TPersistentClass; coItem:TCoreObject; begin for iLcv:=0 to High(CoreObjectItems) do begin ItemP:=CoreObjectItems[iLcv]; coGeneric:=GetClass(ItemP^.ClassName); if (coGenericnil) and coGeneric.InheritsFrom(TCoreObject) then begin coItem:=coGeneric as TCoreObject COMPILER ERROR :-( TPersistentClass(coItem):=coGeneric; Compiles but get Runtime Error coItem.VerifyIDs(Module); CRASH @ RUNTIME end; end; end; How can I get each class's implement of VerifyIDs to get called as each one is different but yet single. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
