From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) by hurricane.the-brannons.com (Postfix) with ESMTPS id ACD8777C83 for ; Fri, 25 Dec 2015 21:45:08 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-01v.sys.comcast.net with comcast id y5lQ1r0042S2Q5R015lQet; Sat, 26 Dec 2015 05:45:24 +0000 Received: from eklhad ([IPv6:2601:405:4001:e487:21e:4fff:fec2:a0f1]) by resomta-ch2-16v.sys.comcast.net with comcast id y5lQ1r0052MDcd7015lQ8N; Sat, 26 Dec 2015 05:45:24 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.6.0+ Date: Sat, 26 Dec 2015 00:45:24 -0500 Message-ID: <20151126004524.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=1451108724; bh=5Gx9fKt4YScnhwBrQFlgW6Ua7zQG+P832i7ekDZeWVA=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=aFheDabr/CH0RNkX5FceYa5vX2VKczIA8TORSP6VBxNJ3JkaXZHVymbxUAWK3PWWs BzzAts/UW3fsRKJuwORpSQJqrRUr9t960Fyfd5ivvRu/Dp7J7/sa8qc5BgtKzESoHN aIss0j2tuJQkSXZpO8bk58R2SMAFHHpXPyGTG9ZHtYPiG5eBZ0ASS8Ii/9c51dAkiX PHSwhbuO+ahImJ5Ur7M0CP5l9gsHKUjE4WUJ6+FRO4Vm9RQ1uHVui5x7N70LY5pu1x im1GN0FeJiAFMekF/HgaCbt8ZoiilXyLRW8xFlDczAYCNtgFvEi0zaZrG6+HBjCOMM 61ZLgEjQqARVQ== Subject: [Edbrowse-dev] curl thread test X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 05:45:08 -0000 In follow up to my previous post on processes and threads, I propose the following small project / test. At present, http or ftp can download in the background, at least on unix. This is useful for large files or slow internet or not a lot of ram etc. It works by forking the process and reissuing the http request. This is harmless 99% of the time, but even here you wonder if the separate processes and separate curl instances could mismatch. You go on to look at 3 more websites during the download, more cookies are added to the jar, then the download finishes and that process writes out the jar and clobbers the new cookies. Since I don't really understand when curl writes the jar it's hard to say whether this could happen or not. With this in mind, how bout this modest project. A download determined to be in the background spins up a thread, rather than forking a process. The thread runs the http request and when that is done it sets, in the appropriate BG_JOB structure, state = 0, then the thread exits. Seems manageable, and it has the advantage of working on windows, which currently does not support the download in background feature at all. Also, and more important, we can test the threadsafe nature of curl. While downloading a large file in background, pull up some other small web pages. Do these all run in their threads, and does the whole assemblage still use one cookie space, making transient cookies available to all threads and consistently writing the cookie jar? We really need to know this. It's incremental, and as Adam writes, it increments us in the right direction. What do you think? Karl Dahlke