edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: edbrowse-dev@edbrowse.org
Subject: [edbrowse-dev] Threads
Date: Tue, 27 Aug 2019 03:19:51 -0400	[thread overview]
Message-ID: <20190727031951.eklhad@comcast.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

Folks, it has happened; i'm using threads for asynchronous downloads instead of processes.
The word fork is not to be found in the edbrowse source!

There are two places this occurs.

1. Download files in background.
This is not the default.
Use the bg command to turn this on.
Usually when a file is large and you just want to let it run in the background.
Type bglist for a list of the background jobs.
Careful, it's not a separate process, so if you quit edbrowse before the download is complete, it just stops and doesn't finish.

2. Download all the javascript files in the background and in parallel.
These can be large files so I'm hoping this speeds things up.
This is on by default because you usually want it, besides,
I really need folks to test it under various conditions
and find any weird race conditions or thread unsafe code or seg falts etc.
It works with curl+gnutls, which the process implementation never did.

Both of these have lots of corner cases, especially #1.
Download ftp files, gopher files, https files, several at onces, some large,
does it all work? Do they interact with each other?
Does the bglist command work?
Does it show the sizes of the downloads in progress?
Does a foreground download still give you the dots?

Are javascript files pulled from cache or put into cache, even when they download in background?
(This is important.)

Then there is a whole host of followup work, like putting off the async scripts til the end,
and maybe starting the js fetches even earlier at parse time,
and maybe fetching css files in background (which isn't done yet),
and on and on.
But first let's make sure I didn't break all sorts of things with this commit.

Set db3 and you'll see all the fetches and http codes etc in a jumbled order as the files are loaded.
Type jsbg to go back to a sserial order.

I've never touched posix threads before so give me a pat on the back for diving into something new.

Karl Dahlke

             reply	other threads:[~2019-08-27  7:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-27  7:19 Karl Dahlke [this message]
2019-08-28  1:30 ` Geoff McLane
2019-08-28  1:48   ` Karl Dahlke
2019-08-28  3:51     ` Kevin Carhart
2019-08-28  4:16       ` Karl Dahlke
  -- strict thread matches above, loose matches on Subject: below --
2014-12-05 21:16 [Edbrowse-dev] Threads Karl Dahlke
2014-12-05 22:05 ` Adam Thompson
2014-12-05 19:29 Karl Dahlke
2014-12-05 20:32 ` Adam Thompson
2014-03-21 22:56 [Edbrowse-dev] threads Karl Dahlke
2014-03-22 21:30 ` 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=20190727031951.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=edbrowse-dev@edbrowse.org \
    /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).