Detect if package is running in another window


#1

I’m working on a package that tails a log file and then streams it to a backend server. My problem is that if another atom window is opened thus activating the package in that separate thread the streaming data gets duplicated. Are there any global flags I could set that are shared between all atom instances?


#2

You could create a lock file and test for its existence?


#3

Yup that seems to be the right idea here… I’m new to shell scripting so learning as I go… My only concern now is finding a cross-platform solution for locking files… flock is for linux while mac os uses shlock


#4

You technically won’t need to lock it… Just create a file next to it…

So ur package activates, checks for the existence of the “lock” file, and returns if the file exists. Otherwise it creates it, and begins tailing the log.
And on deactivate, remove the file again…

Actually locking that file would be a good idea, but not 100% necessary IMO

If you decide to go that route, maybe look at lockfile…


U could just do npm install lockfile --save from a terminal in your package dir.


#5

Thanks for the tip about that npm package! Why do you think it’s not necessary though? I guess I should add that the log file is not being created by my package but instead by a separate bash script completely independent of the package. My package just tails this log file and streams it up to my backend. My goal is to avoid several atom windows all tailing and duplicating data into the stream.


#6

Well, if your atom package is creating the lock file, I cant imagine anything else will even be aware of its existence…
So if you have your package check for the existence of a file, say ~/.loggingActive, and die if it exists, but creeate the file and start tailing the log file if it doesnt, then you should have achieved the goal of only tailing it in one atom instance.
Then in the deactivate function of your main class, have it remove the file before disposing of any of your other atom resources.


#7

Right that sounds good… my only concern is what if atom crashes and the deactivate hook isn’t able to be called. When atom restarts and the package loads it will see the orphaned lock and not start… I think this is why lower level options actually check the OS to see if the PID is running…