stephenbrooks.orgForumMuon1Generalqueue.txt
Username: Password:
Search site:
Subscribe to thread via RSS
Zerberus
2006-09-13 12:29:58
Normally muon1 runs as background app for me (service).  But I like to start the gfx mode from time to time

My problem is: All three possible modes (gfx, cli and background) create and access the same queue file, queue.txt.  It often gets mixed up when using the modes.  (two autosaves, but one queue.txt) Then I may get this error: Failed to delete item from non-existant queue.

I think that: GFX mode should create autogfx.sav and queuegfx.txt, CLI mode autocli.sav and queuecli.txt, and background mode auto.sav and queue.txt.  This way, they would no more mix up.

Is this possible?  Or, can I configure this myself?

Sorry for poor English...
Stephen Brooks
2006-09-14 12:39:36
I guess you could make three separate installs for the time being.  The main reason why I didn't create "multiple queues" is because I thought people just wouldn't run the "alternate" version for long enough to ever complete a queue before going back to their previous mode of operation... But the current way it conflicts isn't good so maybe I should make the filenames separate (you can always rename them if you want to convert a queue from one mode to another).
Stephen Brooks
2006-09-14 12:49:46
I've made that change to the code so this will be in the next version
Stephen Brooks
2006-09-15 11:04:53
Actually, no, I've changed it back again as I tried to make a queue.txt file and forgot the new rules, meaning the program looked for a differently-named file depending on what mode I ran the simulation in.

The rule is that you shouldn't run more than one instance of Muon1 from the same directory, that will always cause problems, because they will at some point try to write to the same results.dat.  Separating the auto.sav files prevented some of the worse corruptions from accidental multiple instances.
Zerberus
2006-09-15 16:15:50
No I don't run the modes at the same time, let me explain...
Before I start the GFX mode, I stop the service.  The problem is, sometimes the background process created QUEUE.TXT which is tied to AUTO.SAV.
The GFX now finishes the QUEUE.TXT and deletes it.  When I later restart the service, it aborts silently because the QUEUE.TXT is missing.
And sometimes I have a very hard time to dicover which of the autosave files created the QUEUE.TXT.
Running two installations is something I don't want to do.
Maybe you could give the choice to the user whether he wants to seperate queue files or not, default to one queue.txt.

Zerberus
Stephen Brooks
2006-09-15 16:18:52
Oh right, maybe I'll put it back then.  I do save queue-related information in the .sav file.  Strictly speaking I could get rid of it but that would make the restoration of save-states even more tricky than it currently is.
HaloJones
2006-09-15 18:37:52
Why must the different modes of operation create different .sav files?  It would be much "nicer" if you could choose the client to match your mood with the client starting from wherever the simulation had left off.
Stephen Brooks
2006-09-18 11:42:06
Yeah but there's a problem with "non-expert" users trying to run the graphical version simultaneously with the background one (or even without knowing the background one is running).

Ideally, one of them could shut the other off, but I haven't looked into how I can do that sort of inter-process communication.  It would be even harder if the background Muon1 was a service.
Zerberus
2006-09-18 21:43:58
You could use a lock file...

1st instance of Muon1 creates a .lock file in Muon directory and keeps it open (no access possible)
any instance of Muon1 started after the 1st one checks for the file and tries to delete/recreate it.  If that fails, Muon1 is running and won't start a second time.  Period.

It would prevent starting Muon1 twice in the same directory...

Zerberus
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io

Site has had accesses.