[fpc-devel] Strange behaviour with Synapse

[Geoffray Levasseur-Brandin]

Le samedi 16 mars 2013 18:25:20 Ludo Brands a écrit :
> There is quite more needed to get the code running. I can't get it
> compiled on my kubuntu 12.04. It complains about duplicate resources.

Hum maybe you have Synapse installed in your Lazarus as I'm briging it with 
the application (and it's appearing in project manage).
> 
> Anyways, looking at the code, you create a thread TDownloadListLoop
> that loops over the files to download. The download is done in another
> thread TDownloadDaemon created in TDownloadListLoop.Execute with
> PDownloader^.StartDownload. TDownloadListLoop.Execute then loops until
> PDownloader^.State = drDone. Now, in TDownloader.HTTPComplete, called
> from TDownloadDaemon.Execute with a synchronize you do
> FState := drDone followed by FDownloadFeedback(FResponse) and a
> FHttp.Clear. Chances are that TDownloadListLoop.Execute continues and
> starts a download of the next file before TDownloader.HTTPComplete
> does the FHttp.Clear. PDownloader^.State = drDone is too early.

You're right this could have been a problem if download parameters are 
different, thank you. Unfortunately, even if this is now corrected, the 
original problem is not solved. Anyway the changes are commited.
> 
> Buy the way, you didn't mention if you encountered the problem with
> http or ftp. So above is just speculation. One of the places where it
> can go wrong.

The two first files are http, then two ftp files, all on the same server (look 
at testconf/depot.conf for the addresses). Each address will need the download 
of two files, paquets.db and applications.db. 

> In any case I don't understand your architecture. Why using a thread
> for the loop, do a HEAD in the same thread and then create another
> thread to do the GET? If you only do one download at a time why the
> 2nd thread TDownloadDaemon? On top of that your code becomes overly
> complex because methods in TDownloader are called in the context of
> the TDownloadListLoop thread and of the main thread (synchronize from
> TDownloadDaemon). A good recipe for race conditions and unreproducible
> errors.

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.
> 
> Ludo

I've made some more test: the bug appaer only if either the application or 
Lazarus (if started from Lazarus) is focussed...
-- 
Geoffray Levasseur-Brandin <geoffray.levasseur-brandin at ac-toulouse.fr>
http://jeff.levasseur.tuxfamily.org/
GNU/PG : BF8BB8407CD26E89466CDA9BB1030FC59EF87775
Errare humanum est sed perseverare diabolicum aut cretinum.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20130316/915c36a4/attachment.sig>