On 2017-02-01 22:44, Jim Mack wrote: > Forgive me if I sounded like I was pushing. I am working daily in OS > development where tools like grunt are commonly accepted, and > developers > accept choices that maximize their power/ease over many other concerns. > I > never heard the slippery slope argument used against node.js, and it > would > surely lose! > > On Wed, Feb 1, 2017 at 2:20 PM, Timothy Hobbs <timo...@hobbs.cz> wrote: > >> Just so you understand the gif, what happens is a client starts up. It >> grabs a lock on the counter file. It reads the counter file. If the >> counter is zero, it launches the service. If it is greater than zero, >> then it connects to the service. After launching or connecting to the >> service, it increments the counter, and releases the lock on the lock >> file. When a client closes, it sends a command to the service, which >> then grabs a lock on the lock file. Decriments the counter, and if the >> counter is now zero, it shuts down, otherwise it merely releases the >> lock. There are no race conditions with this method. If two clients >> start up at the same time, they will have to wait in line for a >> connection to the lock file. If a client shuts down at the same time >> as >> another client starts up, this to means that the service and the >> client >> will have to wait their turns for the lock, and therefore, no races... >> >> >> On 02/01/2017 11:16 PM, Timothy Hobbs wrote: >> > 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 >> >> >> ------------------------------------------------------------ >> ------------------ >> 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 >> > > ------------------------------------------------------------------------------ > 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
No need to apologize, as far as I'm concerned we're just discussing :) Now I hope I didn't sound too rude. I'm just trying to get on the same page with everyone. The provided solutions are in the line of "if the initialization is taking longer than you'd like, here's a way how to initialize only once". My focus is somewhere else though - why is the initialization taking so long? John is saying there's room for improvement, room to do less. -- ------------ Peter Nagy ------------ ------------------------------------------------------------------------------ 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
