Hi Lennart, >>> 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...
I get the feeling that this needs to be measured and someone has to write some performance tool around this. So while you have only seen tiny PAC files, I am seen ours. And that one is massive. I bet that other corporation have similar large ones. Regards Marcel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel