edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] Unwind
Date: Mon, 29 Dec 2014 19:20:03 -0500	[thread overview]
Message-ID: <20141129192003.eklhad@comcast.net> (raw)

The interesting part of moving these downloads to a background child process
is that we have already started the curl download,
and somehow we have to stop it in the parent and keep it going in the child,
all from a callback function.
In the parent, after the fork,
I could setjmp back up the stack, I know how to do it,
but as ANA said in A Taste of Armageddon,
"It would frighten any sane man."
Who knows what sort of curl states would be left about.
So I return -1 from the callback function,
and hope curl unwinds the stack properly, *without*
aborting the transfer on the server side.
So far, for ftp and http, it does.
Have not tested ftps, sftp, or tftp.
The secure ones might be an issue, and similarly for https, also untested.
A future version of curl *might* act differently,
and tell the server to hang up, and then this design won't work.
for now, ftp and http work.
I may have to manufacture tests for ftps and https,
unless someone knows of some handy secure download sites on the net.

Another suboptimal consequence, that we can't do anything about,
is that you can't dawdle when asked for a file name.
The curl download is already in progress, and the server side could well time out
if it takes you two minutes to decide where to put the file.
Fortunately, most people will take the default file name provided by the server,
or type in a quick temp file name to go to the download directory
and then move it later.
That's fine.
I suppose I could test the limits, how long can I delay,
at least here with my local servers apache and vsftpd.

Karl Dahlke

             reply	other threads:[~2014-12-30  0:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-30  0:20 Karl Dahlke [this message]
2014-12-30  4:55 Karl Dahlke
2014-12-30 11:23 ` Adam Thompson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141129192003.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).