Alternative methods for System.gc and ShutdownHook in java - multithreading

We are using System.gc method to halt JVM to delete temp directory,because previously it was not getting deleted,but i got to know that using System.gc or Runtime.getRuntime() is a bad practice,so I Im thinking to use methods others than this ,kindly suggest which one to use.

Manage your resources manually instead of relying on finalizers. I.e. delete the temp directory at the end of the method that created it or if you're using asynchronous control flows then add a CompletableFuture to the end that does the removal.
Use try-with-resources statements to ensure that files only remain open within a limited scope.
On posix systems you can simply delete (unlink) files and (rmdir) directories even if they are still referenced by some file descriptors.

Related

How to open or create a directory if doesn't exist atomically

Is there a way to open a directory and create it if doesn't exist atomically ?
My use case is simple, I use a directory to watch every public key that are allowed to connect to my server, but if the directory doesn't exist I want to create it, unfortunately for now I only see a two step solution, create the path with create_dir_all() and then open it with read_dir() but this create a possible situation where the directory is delete between the two calls (very unlucky in my docker container... but anyway !)
I didn't find any solution in linux to do that and I'm quite surprise cause that a very common operation for file.
I found a related question Create a directory and return a dirfd with `open` but it's focus on file descriptor and so is more specific. The answer seem to say this doesn't prevent race condition, I don't really understand the context, my only concern is to avoid to create the directory and than try to open it and it's fail. It's more for convenience and robustness of code.

When I create a Temporary File/Directory, when will it be removed?

Julia contains a number of methods for making temporary files and directories.
I'm making fairly heavy use of them (and /dev/shm), to inferface with libraries that really want to work with actual files (JLD/HDF5, and OpenStack Swift).
I had been assuming they would be deleted when their finalisers on the pointer to there name were called.
But then after exiting julia it seemed like they were all still there.
Will linux delete them?
If the app didn't clean after itself, the OS will delete the files eventually. It depends on system settings when temp files are deleted. For example, it can happen on boot or nightly (via cron job) or some another way.
See this answer, for example: How is the /tmp directory cleaned up?
What you are likely looking for,
given your surprise that they were not removed, based on going out of scope, as the do block versions of mktemp.
In the very documentation you linked.
mktemp(f::Function[, parent=tempdir()])
Apply the function f to the result of mktemp(parent) and remove the temporary file upon completion.
mktempdir(f::Function[, parent=tempdir()])
Apply the function f to the result of mktempdir(parent) and remove the temporary directory upon completion.
Which you can use like:
mktempdir("/dev/shm") do tdir
fname = joinpath(tdir, name)
#Do some things with your new temp filename `fname` in your tempdir `tdir`
end
#the directory referenced by `tdir`, and `fname`, have now been deleted.

Is there a standard Linux library for "lock files"?

Suppose I have a folder and I want only one instance of my application working on it at a time. I can only synchronize via the filesystem itself. Often times this is a accomplished with something like a .lock_file where if that's present I know another instance is currently using it. Are there any standard libraries that handle this sort of thing?
If you are using C/C++, see fclnt or flock :
Locking files in linux with c/c++
If you are using java, see FileChannel lock method
and
How can I lock a file using java (if possible)
You also can check for the existence of the .lock_file opening it with
open(pathname, O_CREAT | O_EXCL, 0644),
see open man page, it creates and opens the file and returns EEXIST if pathname exists.
In java, calling to File method createNewFile() can be use to create atomically the .lock_file

setupcon use a variant as default

Context
I'm building my complete debian system configuration,
so I'm modifying the keyboard and console setups.
I prefer not to modify the base files to keep a maximum
commpatibility and modularity. So I want to use VARIANT
(see setupcon (5)) and load them at init.
But not sure I'm doing it right.
Desired Architecture
I will only use keyboard file for the following example.
There is the base file /etc/default/keyboard
And two possible custom files (according to setupcon (5))
~/.keyboard
/etc/default/keyboard.variant
~/.keyboard
It provides a custom behaviour per $HOME (user)
/etc/default/keyboard.variant
A global and default keyboard setup
I would like to use the three at a time.
Problem
The daemon calling setupcon are console-setup and console-setup-mini
(according to the coments in their initd scripts). They are started
before login shell, so won't know ~/.keyboard.
setupcon needs to be called
setupcon variant
or, looking at the sources, with a variable $VARIANT
VARIANT=variant
What is the best solution to adopt, saving a maximum modularity.
Thank you,

Application to accept arguments while running

I am using visual studio 2008 and MFC. I accept arguments using a subclass of CCommandLineInfo and overriding ParseParam().
Now I want to pass these arguments to the application while running. For example "test.exe /start" and then to type in the console "test.exe /initialize" to be initialized again.
is there any way to do that?
Edit 1: Some clarifications. My program starts with "test.exe /start". I want to type "test.exe /initialize" and initialize the one and only running process (without closing/opening). And by initialize I mean to read a different XML file, to change some values of the interface and other things.
I cannot think of an easy way to accomplish what you're asking about.
However, you could develop your application to specifically receive commands, and given those commands take any actions you wanted based upon receiving them. Since you're already using MFC, you can do this rather easily. Create a Window (HWND) for your application and register it. It doesn't have to be visible (this won't necessarily make you application a GUI application). Implement a WndProc, and define specific messages that you will receive based on WM_USER + <xxx>.
First and obvious question is why you want to have threads, instead of processes.
You may use GetCommandLine and CommandLineToArgvW to get the fully formatted command line. Detect the arguments, and the call CreateProcess or ShellExecute passing /watever to spawn the process. You may also want to use GetModuleBaseName to get the name of your own EXE.

Resources