Comment 2 for bug 1674053

Revision history for this message
Wayne Stambaugh (stambaughw) wrote : Re: [Bug 1674053] [NEW] curl hangs loading footprints from github

Option 3 would be ideal but I'm OK with option 2. Using a fixed timeout
probably doesn't make sense given the variation in the quality of users
internet connections.

We have common configuration support in KiCad. That's where the
environment variable configuration lives along with other common
settings. You just need to use "kicad_common" as the config file.

On 3/19/2017 12:18 AM, Chris Pavlina wrote:
> Public bug reported:
>
> Occasionally, when loading footprints from github, libcurl freezes in
> curl_easy_perform() waiting on data from the network (particularly on
> Win10 for me). Because there is no timeout, there is no way to interrupt
> it other than by force-quitting kicad.
>
> Please don't immediately run and fix this - as part of my work to add
> footprint selection to eeschema, I've reworked the footprint loading
> into an asynchronous loader, and that changes the ways we can handle
> this. I just want to discuss possibilities:
>
> 1. Add a fixed timeout. This is easily done with curl_easy_setopt();
> we'd have to decide what the timeout should be. Downside is that it's a
> bit ugly. I'm sure no matter what timeout we pick, someone will insist
> it's too short for their slow connection.
>
> 2. Add a configurable timeout. Same as #1 but we also need to make the
> timeout configurable - a bit difficult as the footprint loader currently
> has no simple way I can find to get settings to it, and because the
> timeout setting is not specific to one application (we currently don't
> have a "common" settings panel/category).
>
> 3. Add an abort function. With the asynchronous loader this is possible
> now. libcurl can have a progress callback, which is allowed to return a
> value to abort the transfer. This would require a change to the plugin
> API, because the command to abort has to come all the way from whatever
> called FP_LIB_TABLE::FootprintLoad. Implementation would be simple
> though: async loader objects holds an atomic_bool "m_abort_transfer";
> progress callback checks it; async loader Abort() function sets
> m_abort_transfer true and joins the threads.
>
> Opinions? I'm in favor of #3 but it's also the most work.
>
> ** Affects: kicad
> Importance: Medium
> Status: New
>
>
> ** Tags: cvpcb github pcbnew
>