From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 707FF7884B for ; Mon, 29 Dec 2014 16:22:20 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-08v.sys.comcast.net with comcast id ZcKs1p0074xDoy801cL4bW; Tue, 30 Dec 2014 00:20:04 +0000 Received: from eklhad ([68.84.191.77]) by resomta-po-05v.sys.comcast.net with comcast id ZcL31p00h1gep3001cL4XT; Tue, 30 Dec 2014 00:20:04 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.2 Date: Mon, 29 Dec 2014 19:20:03 -0500 Message-ID: <20141129192003.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419898804; bh=4z1+IMqdgVL820SLwADe1UkbylTOXLDD6+GyLecZT4w=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=esPLRILYBzVsfjkKNAjKIZSl4bm/IeCdcKTOu4koiF4/qFiwtNXQveL6upgqxda5n CARVDwz+2dl6Mu7K32t1+fnOlf9hbYmuDZlOr2MzDyHvUh6VAYzhGxJQL7qYiGXik9 84k5seMOftngobOoefVWJh21cCxgcTXFrh62IIy2tILESSCuVbcFxIMAqq1z9LtA2y 1skISNXUy0adYTaqnqOJ1hqTH5ReI8nh+PGTUyJw2ub+0PHHEFgSmqN97JLh5jDIv9 M44+GacYPDk1sS+n4xKre6qYnSXEnAiS2FiIskgBXjOj9fkdPjteecnFO7blO9e82k RRhUNhZ1qTcyQ== Subject: [Edbrowse-dev] Unwind X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 00:22:20 -0000 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