[systemd-devel] [RFC 4/6] proxy-discoveryd: Execute the PAC based proxy in a thread

[Lennart Poettering]

On Fri, 10.04.15 15:31, Marcel Holtmann (marcel at holtmann.org) wrote:

> > sd-bus is not thread-safe. You cannot send messages from different
> > threads at the same time...
> > 
> > Why precisely do you need threads here? Because the PAC programs might
> > be slow?
> 
> the Javascript execution is normally blocking and it can do whatever
> it wants. If it wants to draw a smiley face, while looking up the
> proxy, it can do that.
> 
> I think the PAC execution needs to be done in a thread, but not the
> D-Bus message handling.
> 
> > WHat about unbounded loops in PAC programs? We need to protect from
> > that, which kinda suggests we muight want to run the PAC stuff out of
> > process so that we can neatly kill the program when it runs for too
> > long?
> 
> Remember that in theory for every HTTP request a browser makes it is
> suppose to ask the PAC file first. Meaning it will run this a
> lot. So spawning processes might be not really useful. Even if we
> start one PAC processing process for each interface, you still want
> threads since you might have multiple requests from different
> application. And if one can be answered from a cache, then you do
> not want to wait until the Javascript execution finished.

Hmm, this really feels like we should still do this out-of-process
with a worker process logic. Reuse processes to keep the cost down,
and run up to a fixed number of them in parallel to allow multiple
sumultaneous requests. THis would have have the major added benefit
that we could lock the worker threads down with seccomp and whatnot,
which is certainly a good thing given that we'll execute foreign,
untrusted code we downloaded from the network with this. And we can
easily kill the execution with a time limit if we desir to do so...

Lennart

-- 
Lennart Poettering, Red Hat