You can use a dbus on-demand service or your own locking mechanism, if you, like me, don't like dbus. Here is a gif which describes the process for starting and stopping a race-free on demand service http://timothy.hobbs.cz/subuser-client-service/lock-file.gif using standard lock files. You can modify this method, so that the service remains running for a certain number of seconds after the client counter has reached zero, so that in a sequential shell script, you wouldn't be launching and stopping the service over and over again.
However, what I was refering to, with shared executable memory, has nothing to do with background daemons. It is a feature that is built into most modern OS kernels. Many kernels load memory pages that are marked as executable as read-only, and share those pages between processes. This greatly reduces startup times, and also improves security (marking them read only that is). It has the dissadvantage, that self modifying code is impossible. Factor, being a weird system that self-modifies itself, cannot take advantage of this mechanism at all. So we'll have to do something more advanced, like use criu, which I linked to previously. On 02/01/2017 11:10 PM, pet...@riseup.net wrote: > On 2017-02-01 19:40, Jim Mack wrote: >> So why not create a separate small process that passes on its >> parameters to >> a running factor if it can find it, or starts a new one if it can't? >> > That's like running a server and sending requests to it. I take several > issues with that: > > 1 - I need one instance to have *all* my libraries, present and future > to be pre-loaded. But more importantly: > 2 - a typical shell script can call a dozen external executables. Some > will be in C, some in bash, some in python, some in perl etc. If every > language would need a huge server to run, where would that leave us? > >> On Wed, Feb 1, 2017 at 7:51 AM, Timothy Hobbs <timo...@hobbs.cz> wrote: >> >>> Have you tried loading the >>> factor interpreter in the background and seeing if factor launches >>> quicker while another factor process is running? > I did what I think is fair - started it once so everything necessary > gets cached in RAM and discard that run. As noted above I don't think > running a server for each possible language is a good solution. > > > Feel free to contradict me gentlemen, I'm open to discussion, but I do > have my own opinion of what is acceptable and transferable to other PCs > / colleagues. I'm not looking for some local hack to speed things up but > a general solution that doesn't put any more burden on the end users > than it is necessary. > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
