Hi Lennart, >>> As it has been discussed in the systemd hackfest during the Linux Conference >>> Europe, one daemon could centralize the management of all network proxy >>> configurations. Idea is something user can do per-application (like in >>> firefox for instance) or broader (per-DM like in Gnome), user could do it >>> once and for all through such daemon and applications would then request it >>> to know whether or not a proxy has to be used and which one. >>> >>> As a notice, this is nothing new. Such standalone daemon has been already >>> done by the past, pacrunner. systemd-proxy-discoveryd will more or less >>> implement the same ideas with improvements. It will get rid of big JS >>> engines like spidermonkey or v8 which are overkill for the tiny PAC files >>> to be executed on, for instance. From pacrunner experience, APIs will be >>> also improved. >> Hi, >> >> the idea of having centralized proxy config is certainly nice. But the >> PAC files make me shiver. So the first question: is it really necessary >> to support PAC files? > > Yes, it's kinda necessary. PAC is pretty widely used in corporate > setting. Windows does the WPAD stuff (the protocol to discover PAD) in > all its versions since a long time. In fact, it immediately issues the > wpad requests as first thing when you plug in an ethernet cable, in > addition to DHCP. > >> Are they widely used in corporate setting or something? >> Is there no saner standard? > > Nope, not really, I fear. > >> >> If the PAC files must be interpreted, I think this is the hardest >> part. FindProxyForURL is started for every request, potentially >> hundreds of times per second and more. This means that starting a >> process per invocation is out of the question, and even starting a >> thread per invocation seems to be too much. But each call fall into an >> infinite loop and hang. So the run time of FindProxyForURL should be >> bounded. FindProxyForURL can also resolve names over the network, >> which would best be done asynchronously. >> >> Things in systemd are usually implemented through poll loops, which >> makes it easy to support thousands of concurrent "jobs". I'd think >> that this would be the best option here too, with a number of "workers" >> executing FindProxyForURL()s and stopping when name resolution is >> requested and continuing when the name is resolved. > > Well, it's Java script code. People can just add code like "for (;;); > ", and we must be able to cancel the lookup then safely. I doubt > that's cleanly doable with either thread-based or event loop based > solutions. I am pretty sure a worker process logic is the way to > go. The worker process should get the PAC data when it is forked off, > and then read FindProxyForURL data from a pipe and output the result > on another, or something similar, and easily sandboxable...
are you sure that you are not overthinking this? I think that duktape actually allows just canceling the JS engine execution, no matter what operation it runs. So you could just cancel the JS context. Regards Marcel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
