[Edbrowse-dev] One program Two processes

[Karl Dahlke <eklhad@comcast.net>]

> The biggest concern is that we have to share a whole bunch of
> HTTP-related state across process boundaries.
> Multi-threading sounds like the answer.

Yes, and the existing message serializing protocol
should prevent the kind of threading nightmares that we've
all experienced in the past.
One thread runs while the other waits.

> wrap all of our networking code in its own process.

Pipes everywhere, looks like a mess,
and where does it end, how many more processes?
Remember that IPC is limited on windows.
I think this creates entropy, whereas one process would probably work just fine.

> allowing edbrowse-js to call into the main edbrowse
> process to make HTTP requests?

We thought about this one before,
when we first learned js had to parse html and create corresponding js objects
right now, as a native method, before the next line of js ran.
Those objects have to be there.
So native code would have to stop and send a message back to edbrowse,
but it's waiting for the return from running the native code,
it's not waiting for a message that says
"hey hold up and here's some html and parse it
and then call me reentrantly so I can create those javascript objects
and then we unwind the stack together and hope that the reentrant calls into js
have not disturbed the thread of execution that was running,
which I can't guarantee for edbrowse or whatever
js engine we're using this week or next week."
Anyways it was way to convoluted, and much easier
to make sure both processes had access to tidy and could do that work.
In the same way, both processes, or both threads,
as you prefer, now have access to httpConnect for making that call.

> Does js really need to have direct, unmediated access to HTTP,

It needs to make the http call before the next line of js code runs.
A native method that does not disturb the flow of execution.


Karl Dahlke