[fpc-pascal] .NET FAQ
I read the .NET FAQ http://www.freepascal.org/faq.html#dotnet. I think the supposed advantage of portability should be refuted more clearly. I think object pascal code compiled with fpc is more portable than the Delphi.NET code. I propose the following change. Current text: There is nothing practical known yet about how portable an average .NET code will be. Little experiments with hello world level code mean nothing, that kind of code works with plain C too. Proposed text: There is nothing practical known yet about how portable an average .NET code will be. Little experiments with hello world level code mean nothing. At this moment object pascal code that can be compiled with fpc is more portable than .NET code that can be compiled with Delphi. What do you think. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
> I think the supposed advantage of portability should be refuted more clearly. > I > think object pascal code compiled with fpc is more portable than the > Delphi.NET > code. I propose the following change. > > Current text: > There is nothing practical known yet about how portable an average .NET code > will > be. Little experiments with hello world level code mean nothing, that kind of > code > works with plain C too. > > Proposed text: There is nothing practical known yet about how portable an > average .NET code will be. Little experiments with hello world level code > mean nothing. At this moment object pascal code that can be compiled with > fpc is more portable than .NET code that can be compiled with Delphi. > > What do you think. Originally that phrase was not just about Delphi.NET, but for "whole" .NET. It was mostly against Mono which was quoted again and again as the perfect substitute, while not even working in theory. However this has changed somewhat, and I'm told most stuff works for at least avg 1.1 C# code. (still don't know anything about the practicality of Delphi.NET -> Mono, and if that only works if the code is crafted) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Threads executing in sequence instead of parallel
On 29/09/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: All gui stuff I run on windows. Non visual test apps, I can run on linux too. If I really want I could do GUI in linux too, but I don't know too much about gtk and I rather spent time on improving things on the windows platform. No problem - maybe someone else in the mailing will spot this and try it under Linux with a GUI. Please post your results if you read this. I thought in your initial mail your were talking about having a console test app with threads. Synchronize is harder then, because you have to call CheckSynchronize yourself. Yes, after the Sort Demo didn't work, I looked for test apps based on threads supplied with FPC. I found one in the fcl/tests directory. It didn't run as advertised of my system either. Not a great demo though. I will try and knock up a better console demo and see if it still does what the GUI Sort demo does. I just need a good idea for a console demo. So far all my tests point to a problem with FPC compiled apps and threading under Linux. Kylix 3 apps using threading works fine as well. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
Current text: There is nothing practical known yet about how portable an average .NET code will be. Little experiments with hello world level code mean nothing, that kind of code works with plain C too. Proposed text: There is nothing practical known yet about how portable an average .NET code will be. Little experiments with hello world level code mean nothing. At this moment object pascal code that can be compiled with fpc is more portable than .NET code that can be compiled with Delphi. I think the proposed one is better. Agree with you. :) I'd also like to question this statement on the same page: > Moreover that also means that existing apps would have to be > rewritten for .NET, since it would take more than a simple > recompile with a FPC/.NET compiler. Why Delphi has no problem supporting .Net without sacrificing backward compatibility (too much)? If I'm not mistaken (CMIIW), during Borcon 2005, Borland demoed a Delphi 1 application (the famous FishFact demo) that can be run on .Net by simply recompile it on BDS 2005. A similar demo is also presented when Borland launched Kylix, simply adding a few $ifdef for q-prefix and then recompile, the Delphi demo application can be running on Linux. I know writing FPC port for .Net is far from easy. But the difficulty should be on compiler code side only. On the user/app code, it shouldn't cause significant changes. Since Delphi and FPC has same language root, object pascal, I wonder why existing FPC apps can't be simply recompile on FPC/.Net? Of course, I never meant it'd work for EVERY kind of apps and codes, but it should work for most common apps. -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
> Why Delphi has no problem supporting .Net without sacrificing backward > compatibility (too much)? There is a problem. > If I'm not mistaken (CMIIW), during Borcon 2005, Borland demoed a Delphi 1 > application (the famous FishFact demo) that can be run on .Net by simply > recompile it on BDS 2005. A similar demo is also presented when Borland > launched Kylix, simply adding a few $ifdef for q-prefix and then > recompile, the Delphi demo application can be running on Linux. So a specially selected demo works. Interesting, but I make full apps, have a certain amount of code that I use that I haven't written. (components) etc. In anything remotely portable, selected demoes work. That is the reason for the reference to "hello world level". Simple, clean stuff always work. But the barrier between native and .NET is about full codebases and the associated components, not about demoes. > I know writing FPC port for .Net is far from easy. But the difficulty should > be on compiler code side only. You can't. Borland also didn't solve this. They did a reasonable job for clean code, but e.g. pointers are unportable. Moreover, what you get is effectively a legacy codebase surviving on .NET, and next week some guy will say "we really have to convert VCL.NET to winforms", or "remove tlist/tstringlist, since they are slow in .NET and use native container types" etc etc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
On Fri, 29 Sep 2006, Bisma Jayadi wrote: > > Current text: > > There is nothing practical known yet about how portable an average .NET code > > will be. Little experiments with hello world level code mean nothing, that > > kind of code works with plain C too. > > > > Proposed text: > > There is nothing practical known yet about how portable an average .NET code > > will be. Little experiments with hello world level code mean nothing. At > > this moment object pascal code that can be compiled with fpc is more > > portable than .NET code that can be compiled with Delphi. > > I think the proposed one is better. Agree with you. :) > > I'd also like to question this statement on the same page: > > > Moreover that also means that existing apps would have to be > > rewritten for .NET, since it would take more than a simple > > recompile with a FPC/.NET compiler. > > Why Delphi has no problem supporting .Net without sacrificing backward > compatibility (too much)? If I'm not mistaken (CMIIW), during Borcon 2005, > Borland demoed a Delphi 1 application (the famous FishFact demo) that can be > run on .Net by simply recompile it on BDS 2005. A similar demo is also > presented when Borland launched Kylix, simply adding a few $ifdef for q-prefix > and then recompile, the Delphi demo application can be running on Linux. Yes, but the fishfact demo is not a real-world application. They might as well have shown a simple "hello-world" application. (ok, stretching it a bit here...) I looked at porting my delphi code at work to .NET. It was simply not possible without an almost complete rewrite of all components we use... own code, third-party code, etc... > > I know writing FPC port for .Net is far from easy. But the difficulty should > be on compiler code side only. On the user/app code, it shouldn't cause > significant changes. Since Delphi and FPC has same language root, object > pascal, I wonder why existing FPC apps can't be simply recompile on FPC/.Net? > Of course, I never meant it'd work for EVERY kind of apps and codes, but it > should work for most common apps. You underestimate the difficulties. The .NET CLR does not know the 'untyped pointer' type. That means that a lot of RTL code must be rewritten; if not most of it. I'm not saying it can't be done, but none of the core developers sees this as a need or even a challenge. Maybe something for the Lazarus bounty system ;) But I'm guessing this would be a rather expensive one ;-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
> On Fri, 29 Sep 2006, Bisma Jayadi wrote: > The .NET CLR does not know the 'untyped pointer' type. That means that a > lot of RTL code must be rewritten; if not most of it. I'm not saying it > can't be done, but none of the core developers sees this as a need or even > a challenge. Moreover, you then still only have a basic ported app in native Delphi style. To benefit from .NET fully, you need another migration/rewrite. And there lies the core for the problem for FPC. For Borland the whole dual platform strategy is a migratory thing (look how neglected win32 is). It makes business sense to make the migration easy, to hold on to old win32 clients. Our "customer" base is largely not interested in .NET though (starting with the fact that half or more of the serious users don't even use windows). And we can't get the dual platform (native/.NET) traject up and running as fast as Borland. There is a fair chance that when we get there, it will be irrelevant, and a split between native and non-native will have occured again. A dual codebase puts limitations on both sides. Native can't use what it is good at (lowlevel interfacing, optimizing stuff for performance), and .NET can't access the gigantic .NET framework because it is not portable to native. Regardless what you think of .NET, I think the dual platform stategy is only a transition horse in time. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
On 9/29/06, Bisma Jayadi <[EMAIL PROTECTED]> wrote: I know writing FPC port for .Net is far from easy. But the difficulty should be on compiler code side only. On the user/app code, it shouldn't cause significant changes. Since Delphi and FPC has same language root, object pascal, I wonder why existing FPC apps can't be simply recompile on FPC/.Net? Of course, I never meant it'd work for EVERY kind of apps and codes, but it should work for most common apps. Hello, My understanding is that enhancing the compiler to generate code for .Net would be only the first step. Next, every single unit included with FPC will have to be re-implemented in .Net . The effort is huge, and the maintainance could be a nightmare. Maybe this is doable, with some substantial sponsorship to support a team of full-time developers. But it's not clear at all that the benefits would cover the resources spent ... By the way : why dotnet and not java ? At least java has been around for a longer time, and there are compatible jdk's for more platforms ... So we wouldn't have to deal with differences like those between Mono and the .Net platform. Cheers, Adrian Maier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] 0.9.18 released
The Lazarus team is glad to announce the 0.9.18 release. This release is based on fpc 2.0.4. This release can be downloaded from the sourceforge download page: http://sourceforge.net/project/showfiles.php?group_id=89339 Detailed list of changes: lazbuild: There is now a command line tool to compile projects and packages called 'lazbuild'. It is built on 'make' and included in all binary packages. See the man page or the wiki or start with -h option to see all options. To build only lazbuild use 'make lazbuilder'. important for win32 users: win32 installer: all fpc binaries and sources are now in the fpc subdirectory. To prevent possible problems install lazarus in a clean directory. win32 installer: localization of context menus debian packages for lazarus and fpc-crosswin32 (for example ubuntu) added scripts to create slackware package for lazarus from A.J. Venter 'make install' now supports INSTALL_PREFIX improved rpm package for SuSE carbon interface: implemented GetWindowSize, GetClientRect, critical sections, LM_SIZE, LM_MOVE, LM_PAINT messages, synchronized gtk interface: added minimum size for TTrackBar, implemented TPage.TabVisible=false gtk2 interface: enabled direct drawing, because it has working event area and double buffering win32 interface: if the OpenFileDialog.FileName contains a directory and ends with a '\', then use the FileName property as InitialDir removed limit on number of selected files (issue 7220) Send LM_CHANGED for TCheckListBox.OnItemClcked qt interface: implemented TListBox TLabel from Felipe basic color handling from zephod updated finnish translation from Seppo Suutarla updated german translation from Joerg Braun and Swen Heinig updated polish translations from Pawel updated dutch translations from Darius updated chinese translations from freefcw updated indonesian translations from Zaenal Mutaqin updated russian translations from Maxim Ganetsky Implemented printer RawMode Access Object Inspector: paste components does not delete components IDE: implemented find next/previous word occurrence. Available in source editor popup menu added InvertColor and RGBColor to graphics.pp from Tom Gregorovic starter: first check in the primary config directory for a Lazarus executable added package for CodeTools added fpcunit tests that compile the examples IDE: added windows version info for projects from Jouke Rensma see Project -> Project Options -> Version Info published TPageControl.OnPageChanged starter: StartLazarus accepts --debug parameter: debug output will be written to debug.log file in the primary config directory (issue 1307) from Boguslaw Brandys TTrayIcon: added x11 version which works under qt LCL help: URL handling with parameters, add firefox to the browserlist, specific location for Safari, added htlmview for Fedora/Suse from Colin Western TBitmap: fixed using destinatin CopyMode from Giuliano Colla Made naming more consistent. Intfxxx methods are called by the interface, WSxxx methods call the interface IDE Find in files and Find: implemented multi line pattern and replacement, regexpr case insensitive, regexpr whole words Hint windows: CalcHintRect now uses screen width as default New IDE menu item: Run -> Quick compile package dependencies: Default filenames for required packages can now be stored in packages and projects. MessageDlg: default button No is now before Abort for Delphi compatibility IDE Help for FPC keywords activated. The help files are not yet in the standard fpc files. Download them separately from the fpc site. codetools: searching macpas unit in macpas mode fixed xml writer to use current line endings TComboBox: KeyDown no longer eats normal keys xml streaming: implemented loading/saving custom properties added gtk X functions to toggle a form fullscreen, limit mouse movement and capture keyboard from Andrew Haines removed xmlreporter unit, now part of the FCL added modified flag to StringGrid find in files: added filter for search results from Funky Beast Unit info dialog: added button to jump to include directive CheckListBox: OnItemClick when using space bar to toggle the checkbox IDEIntf: added IDESearchInText, added text converter tools IDEIntf: added interface for external tools added Procedure Jump to source editor context menu TLabel: not painting background when Transparent=true, and when disabled paint label embossed from Darek source editor now switches to the right, instead of the left when deleting a page from Alexandre Leclerc published TSpinEdit.OnEditingDone IDE codetools: added option to disable adding semicolon for identifier completion added IDE macros: LanguageID and LanguageName bug 1931 DragDrop: sending dmDragMove added bug 1930 implemented freepascal highlighter with nested comments added multithreading examples IDE: edit menus are now disabled if no selection available LCL now uses ClientWidth/Height, when Width/Height is not specified in lfm add
Re: [fpc-pascal] .NET FAQ
On 9/29/06, Adrian Maier <[EMAIL PROTECTED]> wrote: By the way : why dotnet and not java ? At least java has been around for a longer time, and there are compatible jdk's for more platforms ... So we wouldn't have to deal with differences like those between Mono and the .Net platform. Hmm, then we'll be able to show the world the JVM's notorious startup time. In most cases, compiling will be much faster than the app's startup time. The J in JVM probably stands for Jabba the hut . Why not target LLVM instead? Cheers, Krishna -- I long to accomplish a great and noble task, but it is my chief duty to accomplish small tasks as if they were great and noble ! - Helen Keller ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
On 29/09/06, Krishna <[EMAIL PROTECTED]> wrote: Why not target LLVM instead? What is LLVM? Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] .NET FAQ
On 9/29/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > What is LLVM? Check this out: http://llvm.org Cheers, Krishna ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] RE: Threads executing in sequence instead of parallel
Hi - I read enough of this topic to compel me to respond. I have been working with Multi-threading in Free Pascal for a only a month or so now and I learned a great deal - and I have resigned to accepting there are design considerations I have had to adopt to get the results I wanted - that some times seem a bit less than ideal - but the pay offs have been wonderful. Let me digress a little... First of all - THREADS running in a SERIAL fashion... Yup... I had that problem and I resorted to the "SAMPLE" tthreads.pp I think its called, as a starting point. It is an extremely simple example of multi-threading working that comes with either FPC or the FPC source download. I was fighting the serial execution - and then I ran that little tiny test program - and it worked. I tried to fix my code some more - same problem - but the little test program worked... so I finally (this is what I mean when I say I resigned to design changes) adopted that EXACT example as the foundation for how I would implement my THREADS. I create my threads like a thread pool, I create them all suspended. (Because that parts works pretty easy)... I set up the EXECUTE MY THREAD... as a loop... BUT - Each iteration calls its own SUSPEND method So it does a cycle and all I have to do is re initialize the "parameters" it works with BEFORE I resume it So its... as I call it "ready to fire" again, and then I just resume from the main program that is handling all these threads. Basically the test program has a working example of two threads looping at the same time and the simple output shows they are truly multi-tasking... I built my app into this same idea - with the addition that I suspend the loop each go round the suspended threads in turn become my "ready to do something" ones. If they aren't idle - they are either busy or trying to find the meaning of life. One of the biggest "issues" which is hard to debug if you aren't looking for it ... is WHY does a thread stay working when it should have finished the loop? It COULD be a bug in some dumb routine - but in many of my own cases - - it is accessing data that I wanted "SHARED" by all the threads... I know there is this critical section stuff and all that... but I found it simpler to make a RECORD STRUCTURE INSIDE the Threaded class that has all the DATA relevant to that INSTANCE - and then write "shared routines" that PASS this structure by value - so there is less need to worry about sharing data across the threads. I follow two rules - if it MUST be shared - treat it read only. If it can be copied to the thread's instance and does NOT really need to actively traded between the threads, I put it in this record structure - I refer to as "Thread CONTEXT". Now - to handle the ABSOLUTELY MUST allow main app to talk with thread etc. I keep it simple... each thread has a "structure" in the main program's space allocated - and the main program can read an write to it, and the thread can also... I try to keep the data simple - and less consequential to synchronization isn't a big deal - like an IDLE FLAG - or sending a message to the main program. I may write something out there, to a round robin like queue, and manage the pointers, and set up a way for the main program to read the info - when it can in a manner that doesn't interfere with the thread and vice versa. The moral of this story is four fold in my experience so far. 1: ITS Definitely worth it - the speed attained from multi threading, and in many cases the simplicity of having "specific" tasks go away and work and return when finished - well... I enjoy it. 2: Debugging a shared memory thing or one thread stomping another somehow - is a REAL pain to debug... have a great error logging system you can include or exclude with a compiler switch - they are priceless - never too big a log file when debugging -- speaking for myself. My favorite thing is a NEST COUNTER.. and my logs indent the nest level as periods "." so I can see when routines are entered and exited. (I don't use the integrated environment cause I can never get it configured right... I'm a command line junkie) 3: Keep it simple Silly Principle. Advanced methods not working? Resort to something you KNOW works (like the little demo) and build from there. It's often better to go around a mountain than climb the thing. Even though I'm always up for challenges - sometimes ya just need to (Maybe you've heard the famous comedian "Larry the Cable Guy" say this now famous slang term: "Git-R-Dun" (Get it Done ;) 4: Threading IS NOT always the best solution. This has been mentioned in a Lazarus WIKI I read. I'm building multi-user web applications and database stuff etc. So its great for me. If I was making a FTP server like FileZilla - I would do it also - even for the client - separate threads downloading different files at once... But frankly - as many know - sometimes alternatives can actually be faster - like multiplexing - or well managed m
Re: [fpc-pascal] RE: Threads executing in sequence instead of parallel
Some rambling observations: > I was fighting the serial execution - and then I ran that little tiny test > program - and it worked. I tried to fix my code some more - same problem - > but the little test program worked... so I finally (this is what I mean > when > I say I resigned to design changes) adopted that EXACT example as the > foundation for how I would implement my THREADS. I think your issue was possibly related to misuse of API. Certainly, on the WIN32 platform, unless you use the WaitForX or Sleep functions, you'll end up with serial processing because your task is too processor intensive and will starve the other process of any time slices. The scheduler can't context switch as easily if there is a contiguous task taking up processor time, and if you're doing things that can't be interrupted (e.g. copying large chanks of data from one file to another) it can't always (ever?) interrupt the task safely. As mentioned before, use Events, Sepahores and such to create a "state machine" alike. This will then break the work up into chunks, hopefully. Multithreaded programming is a completely different paragdim to standard single threaded programming. > I create my threads like a thread pool, I create them all suspended. > (Because that parts works pretty easy)... Okay, that will work. > I set up the EXECUTE MY THREAD... as a loop... BUT - Each iteration calls > its own SUSPEND method So it does a cycle and all I have to do is re > initialize the "parameters" it works with BEFORE I resume it So its... > as I call it "ready to fire" again, and then I just resume from the main > program that is handling all these threads. Eeek!! Suspending and resuming threads on Win32 is extremely unreliable IMO. Far better to have an event (as in win32 API, not Delphi "Event"), have the thread wait on it being signalled (e.g. WaitForSingleObject) and then restart the thread at that point!! Suspending a running thread is a great way to cause a Deadlock too. > Basically the test program has a working example of two threads looping at > the same time and the simple output shows they are truly multi-tasking... > I > built my app into this same idea - with the addition that I suspend the > loop > each go round the suspended threads in turn become my "ready to do > something" ones. If they aren't idle - they are either busy or trying to > find the meaning of life. Creating threads suspended is a very good idea. This way you can start them in a specific sequence. If you create them as the thread object is created, there is a chance you'll create a race condition because of the potential lag of the data initialization with in your TThread descendent. > One of the biggest "issues" which is hard to debug if you aren't looking > for > it ... is WHY does a thread stay working when it should have finished the > loop? It COULD be a bug in some dumb routine - but in many of my own cases > - > > - it is accessing data that I wanted "SHARED" by all the threads... I know > there is this critical section stuff and all that... but I found it > simpler > to make a RECORD STRUCTURE INSIDE the Threaded class that has all the DATA > relevant to that INSTANCE - and then write "shared routines" that PASS > this > structure by value - so there is less need to worry about sharing data > across the threads. Stay away from Critical Sections. They are a complete hack IMO. They breed logic races. You'll end up debugging weird deadlocks because one thread is waiting to enter a piece of code in a critical section whilst another is in the critical section waiting on the first to complete the task it is waiting on the second to exit the critical section on. And that is just with two threads ;-) Use PostThreadMessage for comms, and don't share non essential data between threads. Create a multiread single write mechanism for your stored shared data. > Now - to handle the ABSOLUTELY MUST allow main app to talk with thread > etc. Use a locking mechanism... Create two methods: function Lock(const timeout: cardinal): boolean; procedure Unlock; make Unlock only Unlock the locker if the lock is owned by the calling process. Make the Lock attempt to lock for up to the timeout (miliseconds) and if the lock fails handle that. You then can gain exclusive access tot he thread. All you then do is make the thread use the locker whenever it accessed the shared data. I suggest using a Semaphone in win32, though I guess a Mutex would potentially work too. Using a semaphore you can extend at a later date to allow mutiple locks. HTH M ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Threads executing in sequence instead of parallel
Thanks Jason - I don't recall you mentioning what platform you are working on, but I gather in is some *nix platform. The only thing you just proofed with your post is - threading is not working correctly! There shouldn't be a need for workarounds like suspending threads to get others to work. The whole point of threads, is let them run all at once in parallel. Delphi does it, Kylix does it, FPC under win32 does it! Linux doesn't! Instead of figuring out a workaround, rather submit a bug report with an example. My apps follow the fire and forget method and it works 100% under Delphi and Kylix, but since I moved to FPC, this is causing more and more headaches. Take on of my apps as an example. I start my app, and get to the login prompt. While I am logging in, the app fires off a thread to populate the lookup tables from a database, another thread loads the application/system settings. I also have another thread that does logging - to file, to console, to a log window or any combination of the three. Each logging type is another thread, and letting them run is serial is not a solution. Neither is playing round-robin with all those threads to suspend one, to get the next one in the queue to run. How does that take advantage of multiprocessor pc's or hyper threading or the new Core 2 Due processors? It doesn't. Make no mistake, I love Free Pascal too and it offers a lot for a great price. All my previous posts, was just me trying to debug the threading and pinpoint the problem. All to make it easier for the person that knows the internals of FPC to fix something like that. I am not a Compiler developer, I'm a Application developer. ;-) After all my tests, I now know it is a bug, and submitted a report on Mantis with two demos. Now the interesting part is how did I get started with all this threading business under FPC.? :-) I needed to port a Kylix app to FPC and wanted to take advantage of threads as the app lends itself perfectly for threading. I thought to test the qualify of FPC threading support, I would first port one or two of the top 10 threading applications that was submitted to Borland in a Threading Contest which Borland held in 2002. Search Borland's CodeCentral or I could post the link. There are some good threading examples available. :-) On 29/09/06, Jason P Sage <[EMAIL PROTECTED]> wrote: Hi - I read enough of this topic to compel me to respond. I have been working with Multi-threading in Free Pascal for a only a month or so now and I learned a great deal - and I have resigned to accepting there are design considerations I have had to adopt to get the results I wanted - that some times seem a bit less than ideal - but the pay offs have been wonderful. Let me digress a little... First of all - THREADS running in a SERIAL fashion... Yup... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Threads executing in sequence instead of parallel
Am Freitag, den 29.09.2006, 19:00 +0200 schrieb Graeme Geldenhuys: > Thanks Jason - I don't recall you mentioning what platform you are > working on, but I gather in is some *nix platform. The only thing you > just proofed with your post is - threading is not working correctly! > > There shouldn't be a need for workarounds like suspending threads to > get others to work. The whole point of threads, is let them run all at > once in parallel. Delphi does it, Kylix does it, FPC under win32 does > it! Linux doesn't! Instead of figuring out a workaround, rather > submit a bug report with an example. FWIW, maybe only to take the general suspicion from unix-like systems: On FreebBSD 4.11 I ran the GUI-threading demo posted by you without any problem in the expected quasi-parallel manner. Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threads executing in sequence instead of parallel
Graeme Geldenhuys wrote:
> We have a problem!!!
>
> The test project /fcl/tests/threads.pp as well as a Sort Demo (Bubble,
> Section and Quick Sort) all execute the threads in sequence, waiting
> for the previous thread to complete, before the next one executes.
> Kind of defeats the point of using threads.
There is no bug. The time slice management is simply different. Try
attached demo (it's your demo modified). You will notice that output
will be mixed.
Linux simply gives longer timeslices to threads (for efficiency reasons).
Micha
program demo1;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}
cthreads,
{$ENDIF}
Classes, SysUtils;
type
// counts up till 1k
TIncrementer = class(TThread)
protected
procedure Execute; override;
end;
// counts down from 1k
TDecrementer = class(TThread)
protected
procedure Execute; override;
end;
TRunThreads = class(TObject)
procedure ThreadTerminated(Sender: TObject);
private
t1, t2: TThread;
FThreadCount: integer;
public
constructor Create;
procedure RunNow;
end;
{ TRunThreads }
procedure TRunThreads.ThreadTerminated(Sender: TObject);
begin
Dec(FThreadCount);
end;
constructor TRunThreads.Create;
begin
FThreadCount := 2;
t1 := TIncrementer.Create(True);
t1.OnTerminate := @ThreadTerminated;
t1.Priority := tpLower;
t1.FreeOnTerminate := True;
t2 := TDecrementer.Create(True);
t2.OnTerminate := @ThreadTerminated;
t2.Priority := tpLower;
t2.FreeOnTerminate := True;
end;
procedure TRunThreads.RunNow;
begin
writeln('RunNow');
t1.Resume;
t2.Resume;
repeat
sleep(100);
until FThreadCount = 0;
WriteLn('All threads completed!');
end;
{ TIncrementer }
procedure BurnCPU(Multiplier: integer);
var
i, k: integer;
begin
k := 13;
for i := 0 to Multiplier*50 do
k := k div 5 * 6;
end;
procedure TIncrementer.Execute;
var
i: integer;
begin
for i := 0 to 1000 do
begin
Writeln(Classname + ': ' + IntToStr(i));
BurnCPU(3);
end;
end;
{ TDecrementer }
procedure TDecrementer.Execute;
var
i: integer;
begin
for i := 1000 downto 0 do
begin
Writeln(Classname + ': ' + IntToStr(i));
BurnCPU(4);
end;
end;
var
lRunThreads: TRunThreads;
begin
lRunThreads := TRunThreads.Create;
lRunThreads.RunNow;
writeln('Done...');
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threads executing in sequence instead of parallel
Graeme Geldenhuys wrote: > The Sort Demo, which is a port of the Threads demo included with > Delphi 7, shows this clearly. I can archive and post the source, but Try inserting some Sleep(0) to force the kernel to switch to another thread ? In real worker threads you wouldn't do this of course, but here just for the visual effect. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] RE: Threads executing in sequence instead of parallel
> I would first port one or > two of the top 10 threading applications that was submitted to Borland > in a Threading Contest which Borland held in 2002. Search Borland's > CodeCentral or I could post the link. There are some good threading > examples available. :-) I have troubles searching. Please, post the link (to the list of rated submissions or something). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Threads executing in sequence instead of
Graeme Wrote: >Thanks Jason - I don't recall you mentioning what platform you are working >on, but I gather in is some *nix platform. The only thing you just proofed >with your post is - threading is not working correctly! >There shouldn't be a need for workarounds like suspending threads to get >others to work. The whole point of threads, is let them run all at once in >parallel. Delphi does it, Kylix does it, FPC under win32 does it! Linux >doesn't! Instead of figuring out a workaround, rather submit a bug report >with an example. -- Jason Now -- Hi Graeme! I always enjoy your posts. I seriously am not cycling the threads like your comment suggests. I actually have proof that the threads are working EQUALLY well in Linux and Win32... BUT this DOESN'T mean they are 100% - because like I was trying to stress... I took that little demo with two simultaneous threads looping, expanded on the "working" model. I can have any number of threads running simultaneously no problem - what I did was make it so - each of my threads "Execute" method - looks sort of like: procedure mythreadclass.execute begin repeat CallSomeCodeHere; self.bIdle:=true; self.suspend; until terminated; end; So I Create a pool of them, set the idle flags to false... why? Just so I KNOW the thread finished the loop and is ready for another go around as I call it. (Geeesh... these self taught guys (like myself) don't even know the nomemclature.. I don't know a semaphore from a mutex for example - but I've dabbled with my own 32 bit OS's with task switching... fun but to much for one person - go figure) So, My Main program is actually a multiplexor - but its concentrating on a little "Windowed" console app - like Free Vision - except mine is homemade from the console, crt, mouse, keyboard units on up. (Mouse doesn't work in my Linux.. but I digress.. prob a gpm thing ) Anyways - as its scanning for user IO at the "server", it has a millisecond timer thing, that basically says every X milliseconds, see if there are any new arrivals - (jobs to do) - and then it grabs info about all the new arrivals until processed, in this order 1: Look for those IDLE threads in the thread pool, Got One? Cool, (Its still suspended) 2: load up the variables in the thread pertaining to the JOB - basically initialize it with all the info it needs to perform a cycle 3: "RESUME IT"... Good Bye thread - its off and running. I don't even THINK about it again until its idle again... (well, the main program doesn't even consider it - I should say - until its self.bIdle=TRUE) so I'm not doing all this thread micro-management that your comment seemed to suggest, and was a response to. 4 meanwhile main program finishing "launching" work tasks, and when done, goes back to UI stuff, and what ever. This all happens very smoothly and I don't think I'll need to change this architecture until my web applications are getting nailed like 50 requests a second or something - where WORK TO DO makes the SERVER UI to unresponsive under load. Either way - I just change the LOOP that tries to tackle all pending work at once - to a controlled number, and grab more stuff each go round... Behind the scenes - the threads are purring away - I have a couple "SLEEPS" here and there - but only when it seems appropriate - like the "THREAD is waiting on something..." ... on in the main program - ... but these are not related to each other - just my program trying to give up the CPU when its, (in one program I have a flag literally named) "bTrulyIdle". Truly Idle menas - I looked around - there's nothing to do so it "Sleeps" (Actually in my prog - if win 32 I call win32 API - and in linux I use sysutils sleep, so I have a function called "Yield" that wraps this up rather nicely .. I have reasons - I TRY to not use sysutils in ONE app due to EXE size reasons - but in linux I just deal - cuz I need the SLEEP function - in all my other apps SIZE is not a factor - straight up speed is - (Free Pascal seems GREAT to me in this arena) Jason P Sage ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threads executing in sequence instead of parallel
On 29/09/06, Micha Nelissen <[EMAIL PROTECTED]> wrote: There is no bug. The time slice management is simply different. Try attached demo (it's your demo modified). You will notice that output will be mixed. Linux simply gives longer timeslices to threads (for efficiency reasons). Micha Ah, finally some explanation that makes sence! Thanks Micha, your modified demo does in fact make Linux switch between threads. I also tried the Sleep(0) you mentiond in the Sort Demo. Sleep() didn't do the trick, but using the BurnCPU() method from Demo1 did. Where can I read more about the timeslices to threads under Linux. It obviously works vastly different to Windows (and FreeBSD as someone pointed out). This sounds like an interesting topic and something work understanding. After all, it gave me enough headaches and a false positive - thinking it is a bug. Sorry for all the trouble... :-) Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] RE: Threads executing in sequence instead of parallel
On 29/09/06, Пётр Косаревский <[EMAIL PROTECTED]> wrote: > I would first port one or > two of the top 10 threading applications that was submitted to Borland > in a Threading Contest which Borland held in 2002. Search Borland's > CodeCentral or I could post the link. There are some good threading > examples available. :-) I have troubles searching. Please, post the link (to the list of rated submissions or something). Try the following: Aboute the Contest http://bdn.borland.com/article/28448 Fun with Threads http://www.thedelphimagazine.com/samples/1712/1712.htm The winners http://bdn.borland.com/article/0,1410,29786,00.html Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Threads executing in sequence instead of
My apologies Jason. I totally miss understood what you meant in your first email! The second post explained it much better. Yeah, it's Friday - my brain was already in weekend mode, but my body stuck at the office. A terrible situation to be in. :-) Regards, - Graeme - On 29/09/06, Jason P Sage <[EMAIL PROTECTED]> wrote: Graeme Wrote: >Thanks Jason - I don't recall you mentioning what platform you are working ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
