1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: autosave limitation? |
From: | Emmanuel Mayssat <[email protected]> |
To: | Tim Mooney <[email protected]> |
Cc: | emmanuel mayssat <[email protected]>, "[email protected]" <[email protected]> |
Date: | Wed, 17 Apr 2013 11:14:29 -0700 |
Can this value be increased in the source instead and be available in the next release (whenever that is)? Applying a patch as simple as this requires - create the patch - modify the autosave installation script to apply patches - document the change - inform QA - inform coworkers when 6 months later, you have machine operations issue and you realize that - a rogue IOC - installed by an intern - who did not read the documentation - did a manual install and was unaware of the patch - ... <insert worse case scenario here>... including downtime and hardware damage ;-) Could you please increase the value of MAXRESTOREFILES (or implement a chained list) in the next version of autosave? Regards, -- Emmanuel > There's no real reason autosave is limited to 8 files, other than that I > didn't know anyone wanted more than that. I haven't tested large numbers > of files, but you can edit save_restore.h and change > #define MAXRESTOREFILES 8 > to whatever you want. The number of save files is already unlimited (you > can make as many create_monitor_set() calls as you want.) > > Yes, the number of restore files could be made unlimited. That's what I > meant to imply when I said that the list of restore file names could be > implemented as a linked list. If someone wants 1000 files, then a linked > list is probably called for. If 30 is enough, then > #define MAXRESTOREFILES 30 > seems adequate. All we're doing is allocating an array of pointers. > > Tim > > -- > Tim Mooney ([email protected]) (630)252-5417 > Software Services Group (www.aps.anl.gov) > Advanced Photon Source, Argonne National Lab |