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

[Marcel Holtmann]

Hi Lennart,

>> +static void *run_thread(void *data) {
>> +        _cleanup_free_ struct proxy_parameters *params = NULL;
>> +        _cleanup_pac_free_ struct PAC *pac = NULL;
>> +        _cleanup_free_ char *result = NULL;
>> +        const char *url, *host;
>> +
>> +        params = data;
>> +
>> +        if (sd_bus_message_read(params->message, "ss", &url, &host) < 0)
>> +                goto answer;
>> +
>> +        if (pac_load(params->proxy, &pac) < 0)
>> +                goto answer;
>> +
>> +        pac_execute(pac, url, host, &result);
>> +
>> +answer:
>> +        if (!result)
>> +                result = strdup("DIRECT");
>> +
>> +        sd_bus_reply_method_return(params->message, "s", result);
> 
> 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.

Regards

Marcel