[Edbrowse-dev] JS1

[Karl Dahlke <eklhad@comcast.net>]

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

This is either for fun, or for testing, or for the future. I'm not sure.

export JS1=on

Set this to any nonempty value, and edbrowse remains one process. It doesn't fork off a copy of itself to manage the js.
The default is as it was, 2 processes and pipes.
The first implementation of this feature was easy peasy, almost too easy.
Leave all the pipes up and don't do the fork.
Send messages through the pipes and back around to the same process.
After edbrowse has sent a message to js, and is waiting for a response, it does this.

		whichproc = 'j';
		processMessage1();
		whichproc = 'e';

processMessage1 is in jseng-duk.c and it reads and processes the message and writes the response back to the pipe, back to edbrowse.
So it looks like the other process ran.
whichproc j or e makes the single process believe it is running as the js process then as edbrowse again.
If you just joined us and looked at the software, and thought we routinely ran as one process, you'd think it was the stupidest design ever.
Sending messages out through pipes and back to myself instead of just calling the functions that are right there.
But it's evolution, isn't it?
It reminds me of the gene that manufactures vitamin C, the gene that works in most animals, but not us.
It's broken in us, it's still there but broken, so we have to eat fruit or die of scurvy.
But I digress.

This worked for jsrt and all my local tests, but not in the real world.
Websites can have large strings, and these can be part of the messages.
When you push a long message into a pipe, it blocks until somebody reads part of it from the other side.
That's how pipes have worked since 1980.
With nothing asynchronous reading from the other side, everything stopped.
Oops.
So I bypassed the pipes and put the message in memory.
Then the other simulated process reads it from memory, writes the reply in memory, and so on, and that works.
It's still a modest change, and only comes into play if JS1=on.

For nearly 2 years Adam has told me we should stay with 2 processes, and so far he's been right all along.
When js crashes, and it still crashes a lot, at least you keep your websites and the book you were reading and the email you were writing and so on.
And of course the 2 process messaging API is great encapsulation, and meant I could switch from mozilla to duktape in 3 weeks instead of 6 months.
All good, but the separate processes and spaces cause trouble.
Keeping a consistent set of cookies in the two curl spaces is not easy, and I'm still not sure we're doing it right.
You can test it with JS1=on, one curl space, and see if the website renders properly.
Or consider the code Dominique is working on right now, the domains and passwords for 401 authentication.
He wouldn't need to do any of that if it was one process.
But it's two, so he has to write code to pass all that stuff in messages through pipes and down to the js process.
Well before any of this is written he can test it in one process to see if the authentication works for both edbrowse http fetch and js http fetch.
It's a way to compare the two worlds.

Wil one process some day be the norm?
Wouldn't change the user interface, so it's entirely up to us.
Maybe someday, and boy could we simplify the code!
But not until js is rock solid and just plain doesn't crash. We're not there yet.
Example, we call tidy to parse html, and we don't feel like we need a separate process and pipes to do that, because tidy doesn't crash.

Karl Dahlke