edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Karl Dahlke <eklhad@comcast.net>
Cc: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] interprocess messages
Date: Tue, 9 Dec 2014 18:23:04 +0000	[thread overview]
Message-ID: <20141209182304.GR14122@toaster.adamthompson.me.uk> (raw)
In-Reply-To: <20141109091302.eklhad@comcast.net>

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

On Tue, Dec 09, 2014 at 09:13:02AM -0500, Karl Dahlke wrote:
> > 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.

Right, when I did this last time I landed on message queues eventually since the interface was a bit nicer to use (you put a message in, you get a message out, no need to worry about reading the correct amount etc), but I don't really mind any of the three.
> 
> > 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.

Agreed (though on a scalability note, as we're on linux anyway,
I'd go for epoll over select, but select is more portable,
and with 3 descriptors there's no noticeable, or probably measurable,
performance difference).

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

Sounds good.

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

Yeah, that does sound rather concerning.
When I've got a bit of time (this weekend may be) I'll have a look at the Debian packaged version and see how far I get.
I'm also investigating if there are any other js engines which are in a
suitable state for use in a web browser.
I've got no solid candidates yet but I've got a couple of ideas.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  parent reply	other threads:[~2014-12-09 18:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-09 14:13 Karl Dahlke
2014-12-09 15:57 ` Chris Brannon
2014-12-09 23:01   ` Adam Thompson
2014-12-09 18:23 ` Adam Thompson [this message]
  -- 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

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=20141209182304.GR14122@toaster.adamthompson.me.uk \
    --to=arthompson1990@gmail.com \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    --cc=eklhad@comcast.net \
    /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).