Re: Concurrency, again

[Eli Zaretskii]

> Date: Mon, 17 Oct 2016 13:53:53 -0400
> From: "Perry E. Metzger" <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 
> Well, active content like video or audio too.

Isn't that already asynch in nature?  IOW, isn't it right that you
write the stream to some system API, which then plays it
asynchronously at its own leisure?

> For good or ill, though, active content is now most of the
> web. Also, the line between JavaScript and active content (like
> HTML5 video) is often thin. If one wanted to have Emacs be a truly
> effective browser, it would need the ability to deal with this.

Emacs can deal with that if the service which performs the job can
present a 'pselect'able interface.  That could be an API or a
subprocess (of any type we support, including a socket).

> I think having Emacs be a truly effective browser is a very useful
> goal btw.

I don't.  I think it's good to have Web browsing facilities in Emacs,
including EWW, but making Emacs a browser that can compete with the
likes of Firefox and Chrome should not be our goal, because we will
never succeed (and we don't have to).

> I love the idea of never having to leave emacs again.

You are "leaving" it already: for compiling, for grepping, for talking
to MTA, for spell-checking, etc.  Emacs cannot do everything, it can
only ever hope to have an interface to everything.  And browse-url is
as good an interface as any.

> Of course, one could do something like wrapping the Webkit instances
> in subprocesses, which might not be awful from an isolation
> viewpoint. Still, that leaves the question of how to handle the
> interaction with such a thing.

The way we always do: through pselect.  Which is a proper interface
for handling multiple streams of data.

> I suppose part of the problem here is that the existing Emacs
> implementation goes back to an era before such things could have even
> been contemplated.

What problem is that?