Re: [fpc-devel] Strange behaviour with Synapse
On 03/16/2013 07:55 PM, Ludo Brands wrote: On 03/16/2013 07:29 PM, Geoffray Levasseur-Brandin wrote: This is somewhat complex, I know it, but this have been created keeping in mind that I would like to allow parallelization of downloads in the future, as you was supposing it. But I'm agree and if someone have an idea on how simplifying it and almost in a more secure way, allowing parallelization in future I would very appreciate it. Instead of re-using TDownloader.FHttp: THTTPSend for all threads, create a THTTPSend per TDownloadDaemon. You have to use multiple THTTPSend instances in any case if you want to do parallel downloads. Actually, get rid of TDownloader and do everything in TDownloadDaemon. Even the HEAD. Also, get rid of all these synchronizes. When using multiple threads, you will be blocking your downloads too much. Every sock status change, you create a string for the GUI, synchronize to update the screen, call Application.Processmessages to make sure the GUI gets updated. That is a huge waste of resources and slows down downloads considerably. On top of that you have timers that also update the GUI. Turn this around. Have TDownloadDaemon do the complete download and nothing else. Put status in properties of TDownloadDaemon, using a critical section if you want to pass strings, and poll your download threads in the main thread to update the GUI. You have already a timer. Make it faster (fe. 200ms) and update your GUI from there. Nobody will see the difference. No more synchronize and Application.Processmessages anymore and your program flow becomes so much easier. Multi-threading is difficult and simplifying your program flow is key to getting it right. I changed the project to GTK2 and got it running. It crashes not always at the same time but it is systematically in the synchronize in TDownloadDaemon.SockStatus and always when doing the HEAD. So that is a synchronize called inside a synchronize from the TDownloadListLoop. You should not call synchronize from the main loop. Worse, TDownloadDaemon.SockStatus calls Synchronize(FOnProgress) which calls TThread.Synchronize(self,AMethod). Self is TDownloadDaemon but since you call TDownloadDaemon.SockStatus here from the main thread, synchronize uses the wrong AThread. The first download it happens to work because there is no thread running when you do HEAD. The second time you aren't that lucky. In any case, this is an overly complex program flow and is simply asking for problems. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Solved] Strange behaviour with Synapse
Le dimanche 17 mars 2013 09:05:45 Ludo Brands a écrit : Also, get rid of all these synchronizes. When using multiple threads, you will be blocking your downloads too much. Every sock status change, you create a string for the GUI, synchronize to update the screen, call Application.Processmessages to make sure the GUI gets updated. That is a huge waste of resources and slows down downloads considerably. On top of that you have timers that also update the GUI. Turn this around. Have TDownloadDaemon do the complete download and nothing else. Put status in properties of TDownloadDaemon, using a critical section if you want to pass strings, and poll your download threads in the main thread to update the GUI. You have already a timer. Make it faster (fe. 200ms) and update your GUI from there. Nobody will see the difference. No more synchronize and Application.Processmessages anymore and your program flow becomes so much easier. Multi-threading is difficult and simplifying your program flow is key to getting it right. I changed the project to GTK2 and got it running. It crashes not always at the same time but it is systematically in the synchronize in TDownloadDaemon.SockStatus and always when doing the HEAD. So that is a synchronize called inside a synchronize from the TDownloadListLoop. You should not call synchronize from the main loop. Worse, TDownloadDaemon.SockStatus calls Synchronize(FOnProgress) which calls TThread.Synchronize(self,AMethod). Self is TDownloadDaemon but since you call TDownloadDaemon.SockStatus here from the main thread, synchronize uses the wrong AThread. The first download it happens to work because there is no thread running when you do HEAD. The second time you aren't that lucky. In any case, this is an overly complex program flow and is simply asking for problems. Ludo Thank you for all the advices. I just removed TDownloadDeamon thread to merge it with TDownloader. And it works ! I still have to work on status/progress system which is a bit messy. If you are interested, I've just commited the changes in the svn repo. Thank you again, -- Geoffray Levasseur-Brandin geoffray.levasseur-bran...@ac-toulouse.fr http://jeff.levasseur.tuxfamily.org/ GNU/PG : BF8BB8407CD26E89466CDA9BB1030FC59EF87775 Errare humanum est sed perseverare diabolicum aut cretinum. signature.asc Description: This is a digitally signed message part. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Solved] Strange behaviour with Synapse
Thank you for all the advices. I just removed TDownloadDeamon thread to merge it with TDownloader. And it works ! I still have to work on status/progress system which is a bit messy. If you are interested, I've just commited the changes in the svn repo. Thank you again, I noticed you are now calling Application.ProcessMessages in TDownloader.SockStatus. You shouldn't make that call from a thread. It will try to handle the messages from the thread. Perhaps the widget set has some protection for that and will ignore calls coming from anything but the main thread but I doubt it. It'll cause sooner or later big problems. Get your GUI stuff out of the download thread. It pays to have clean and understandable threads. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc 2.6.2 - heaptrc and dwarf will crash
It seems that in FPC 2.6.2 the dwarf reading code in LnfoDwrf is broken.
It always gives a run-error 131
compiled below example with
-MObjFPC -Scghi -O1 -gw2 -gl -gh -vewnhi
and boom
program Project1;
{$mode objfpc}{$H+}
begin
TObject.Create;
end.
it prints
Heap dump by heaptrc unit
1 memory blocks allocated : 4/8
0 memory blocks freed : 0/0
1 unfreed memory blocks : 4
True heap size : 98304 (112 used in System startup)
True free heap : 98112
Should be : 98120
Call trace for block $00087458 size 4
$00401427 line 6 of project1.lpr
and then 131 is risen
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 06.03.2013 14:16, schrieb Martin Schreiber: On Sunday 03 March 2013 18:35:53 Martin Schreiber wrote: On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3 A last one, simple MSEgui demo, one form, a fancy tlabel, one button: http://mseide-msegui.sourceforge.net/pics/kylix3.png Program size Kylix 3: -rwxr-xr-x 1 mse users 1038420 Mar 6 13:28 kylixdemo FPC 2.6.2, commandline: ppc386 -okylixdemo -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/linux/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fi/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/*/ -B -O2 -CX -XX -Xs kylixdemo.pas Program size: -rwxr-xr-x 1 mse users 1252204 Mar 6 14:10 kylixdemo Without the used sources it is of very little use. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] Mantis issue 9961
Am 10.03.2013 18:53, schrieb Aleksa Todorovic: Hi, FPC developers! I've commited patch to issue 9961 few days ago, and I'd like to ask if someone could take a look at it? I'm currently analyzing several other unit-loading issues (10551, 18294) with similar situations (relative paths, different unit loading order when compiling and loading ppu), but I'd like to get opinion on solution for issue 9961, if it's possible :) It looked good to me, thanks! I committed it as you might have noticed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
