edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [Edbrowse-dev]  interprocess messages
@ 2014-12-09 14:13 Karl Dahlke
  2014-12-09 15:57 ` Chris Brannon
  2014-12-09 18:23 ` Adam Thompson
  0 siblings, 2 replies; 7+ messages in thread
From: Karl Dahlke @ 2014-12-09 14:13 UTC (permalink / raw)
  To: Edbrowse-dev

> Pipes, sockets or message queues would be the three I'd think of here.

Right. Probably pipes cause it's easy, but it mostly doesn't matter
and could be easily changed one to another.

> how would this play with blocking calls,

All three of these, and any others you might think of,
block by default, and can also be set nonblocking,
but I've learned over the years nonblocking is a bad idea.
Never make a nonblocking call.
My jupiter speech adapter for example - reads index markers
coming back from the synthesizer asynchronously, and your keyboard commands,
perhaps telling speech to shut up, and maybe speech
commands coming from other processes through the fifo /etc/jupiter.fifo.
Three asynchronous streams to monitor simultaneously,
and the right way to do this is by calling select.
In other words, if a primary process is monitoring many asynchronous
events from other processes / streams, select() is your friend.
It does exactly what you want.
This is deep in the kernel, and thank god they put it there,
because you just can't simulate it through any kind of user space programming.
Anyways, I believe we will be able to migrate to various asynchronous events,
ajax, download to disk in background, etc etc, when the time comes.

I will see if I can bang this first step out,
partly because I haven't programmed in about a year,
and I find that I really miss it.
When you're not programming for your boss / professor, it really is fun.
I estimate a couple of weeks.
Meantime you (plural) might look at v8 and just evaluate.
I still haven't gotten a hello world program to compile,
and honestly that concerns me.
Much of their documentation is all excited about setting speed records,
and compiling js code into native cpu code for speed.
Really? A true js compiler?
What the fuck for?
To see how fast you can jerk off?
As we've said so many times, performance is not really an issue here,
how about reliability and portability and flexibility?
The last thing I'd want to do is turn js into machine code.
Well google sometimes does things just to do them, just because they can.
Still it looks like a cleaner interface, without all the compartment confusion,
and I'm sure those compartments are really going to haunt us when one js
context travels through document.frames[2].whatever to access another context.
We don't do this stuff now and we need to and I'm not sure
how to cross into the other compartments
and honestly I'm not sure how firefox does it eithere, but it must.
I'm thinking intercontext stuff is easier in v8.
But I really don't have a clue.
Anyways, I'll get back to my ipc work, which is moving forward nicely.
Chris, as maintainer you might want to ask if we should mark
another version before taking the ipc step.
I think there were just little tweaks here and there since 3.5.1,
but some of them fixed some small bugs.
Look at logs and see what you think.

Karl Dahlke

^ permalink raw reply	[flat|nested] 7+ messages in thread
* [Edbrowse-dev] interprocess messages
@ 2014-12-08 19:27 Karl Dahlke
  2014-12-09  7:53 ` Adam Thompson
  2014-12-09 11:06 ` Chris Brannon
  0 siblings, 2 replies; 7+ messages in thread
From: Karl Dahlke @ 2014-12-08 19:27 UTC (permalink / raw)
  To: Edbrowse-dev

As promised, here are some thoughts on messages between eb and the back-end
js process.
Please remember that this is intended as increment,
and so there are messsages to do the things we do today,
while other messages and functionality will come later.

Edbrowse currently maintains a session number,
which is printed by the e command.
In addition to this, edbrowse will maintain a stack number for
the buffers that stack up per session.
Session number and stack number
determines uniquely an edbrowse buffer, a window/document,
and a javascript context.
This combined number will be the context number,
passed between the two processes to identify the js context.

e www.ibm.com
session 1, stack 1, context 100001 (or some such).

Upon browse, if js is not disabled,
eb sends message to js to create the context.
If js is not yet launched, fork/exec the js process.
This process creates the js runtime, allocates the heap, etc.
If this initialization cannot happen it returns an error,
which edbrowse prints, and then disables js,
so you don't get this error again and again on every browse command.
So let's assume js launches and succeeds with a runtime environment.
It creates the js context for the corresponding edbrowse window and returns.

If at any time the js process dies, or is killed,
edbrowse cannot read or write to said process.
At this point it loops through all windows in all sessions
and sets js_dead = true in each of them.
The next browse will reinvoke the js process, as if it were the first browse.
If this succeeds, then in any other session you can unbrowse
and browse, and that action will create a fresh js context for that session.
You could perhaps restart a preexisting web page, even after a js disaster.
Of course we hope these disasters are rare.

There is something that is never done today, but must happen in the future.
One js context, through frames or parent pointers,
can access or modify variables in another js context.
This is another reason to keep them all in the same process.
I'm going to hold off on this for a future incremental step,
but it needs to happen some day.

So far we have the first message, and a status return:

1. create java context for this context number

The next message is of course, and predictably,
to destroy the context, because the window is closed.

2. distroy javascript context for this window

3. destroy javascript runtime process, issued when edbrowse quits completely.
Even if you didn't issue this message, edbrowse exits, and then js exits
on broken pipe.

Subsequent messages fetch or establish objects in the js world,
or properties of those objects.
The return from each request begins with a high level status code.
0 = ok
1 = syntax error or other problem with this particular command.
2 = this js context has failed, set js_dead = true
3 = the entire js heap is compromised, set js_dead = true
   across all sessions and all windows.
4 = js cannot run, no fork, no exec, no js runtime, etc.
   Mark each buffer with js_dead = true and also disable javascript
   so this error does not come again and again with each browse.
   Of course you can re enable javascript and try to browse again.
   Error 4 can only arise from the create java context request.

After the high status number is a low status number,
that edbrowse can use to print a particular error message.
If the status is 0 = ok then the rest of the message
returns whatever edbrowse was asking for.
With this in mind, here are some more ipc messages.

Just as contexts have numbers, so objects within contexts have numbers.
These are assigned by the js process.
They must be, since running javascript can create more objects,
quite apart from those initially created by html.
If edbrowse asks js to create an object corresponding to a dom entity,
js will return the number of said object for future reference.
More on this below.

4. compile and execute a chunk of js code.

5. get property from an object, passes object number and property name,
returns type indicator and a string representation of the property.
Property could be string, integer, float, boolean, function, or another object
whence the presentation is the object number.

6. set property within an object, passes object number,
type of property, and string representation of that property.
Additional parameters are create, when the property is created first time,
and readonly, if the property is created readonly.
Nothing is returned, other than the usual status bytes.

7. Run function, usually an event handler.
pass the dom object number that is the "this" for the running function,
and the name of the function.

Perhaps 2 or 3 more ipc messages that I haven't thought of,
but this should give us the functionality we have today.

Around this I would write wrappers that are essentially the
same functions we have today.
So get_property_string would do what it does now but do so by passing
a message and getting a response.
As much of this as I can do, would make it that much easier to switch over
to the interprocess system.
It would be a manageable increment.

Karl Dahlke

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-12-09 23:03 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-09 14:13 [Edbrowse-dev] interprocess messages Karl Dahlke
2014-12-09 15:57 ` Chris Brannon
2014-12-09 23:01   ` Adam Thompson
2014-12-09 18:23 ` Adam Thompson
  -- strict thread matches above, loose matches on Subject: below --
2014-12-08 19:27 Karl Dahlke
2014-12-09  7:53 ` Adam Thompson
2014-12-09 11:06 ` Chris Brannon

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).