On Mon, Jan 05, 2015 at 04:25:26PM -0800, Chris Brannon wrote: > Karl Dahlke writes: > > > then maybe we shouldn't spend a lot of time tracking it down. > > I wasn't asking for the feature in the first place. > > Me either. I use GNU screen, so if my edbrowse blocks, I just open up > another screen window and fire off another browser. > The saving directly to disk feature is nice though, since that's what > people are usually going to want to do with extremely large files. > I do see why some folks would like downloading in the background, so > if I can figure out why it barfs on https, I will. Thanks. The problem I've ran into on more than one occasion is that edbrowse supports multiple buffers and yet blocks on large downloads. This means that if I'm working in edbrowse and start a large (or more likely just really slow) download, then I can't use the other edbrowse buffers I've got open whilst the download happens. Tbh, before edbrowse got saving to disk, I rarely used it for large downloads because most of my machines are memory limited (1 gb of RAM counts as memory limited when you try downloading a 1.5 gb iso by mistake), however now I'd like to be able to download files just like I'd do in a graphical browser, or when using links (which I sometimes have to do when edbrowse won't handle a site's particular kind of html) for that matter. > Something tells me that it's not ok to use the same curl handle across > multiple processes though. More research is required. Yeah. I'm not sure if it's a factor since I've never ran into this before, but when running in gdb you can see that curl launches a new thread when performing network operations. I wonder what happens when one forks the process mid operation, and how that plays with whatever openssl is doing behind curl's threading. Cheers, Adam.