On Wed, Dec 23, 2015 at 10:09:28AM -0500, Karl Dahlke wrote:
> this is an incremental step.
> Moving towardes a merged solution with one instance of curl,
> one set of cookies etc,
> there is now just one executable, edbrowse,
> which runs as either edbrowse or edbrowse-js depending on its name.
> Like gawk and awk in /bin
> So still two processes, same interface, same pipes
> and messages, same communication, but one target
> that is linked to both names.
> Eventually edbrowse will spin off js as a thread,
> not a fork exec of the same program under a different name,
> and then we won't have to worry about replicating or losing cookies etc.
> Will also smooth out the differences between linux and windows,
> which are considerable any time you say the words fork exec.

My initial reaction to this was... very worried,
certainly about the suggested "thread safe" design.
I've seen projects which do this kind of half-done multi-threading and they
rarely end well. However, I'd personally be in favour of a hybrid design.
A sort of multi-process multi-threaded mechanism.

that being said, we can certainly do better than a fork exec with the copy and
symlink approach. There's no need now to have the executables separated like
that if we're comfortable linking the functions in the js engine,
simply fork once we've set things up and we get the structures etc for free.
As for your assertion about stability,
I'm now regularly seeing edbrowse-js seg faults again, not sure why,
although it looks like the process is using a lot of resources when it does this.

I'd rather we had a proper discussion about this stuff before heading off in a
direction like this, particularly as I was planning on doing some xhr stuff.

Cheers,
Adam.