Re: [fltk.general] OT: Making application run once
For portability, I use boost::interprocess::file_lock::try_lock() upon some existing common file. (if it fails, program is already running so you can either exit or send to the other process program arguments or so...) Some parts of boost libraries are nice, some are ugly and bloated as hell... Interprocess is OK(ish). R. On 16/02/2013 13:10, Gonzalo Garramuno wrote: I would like my application to have only one instance of it running at a time. However I am unsure how to implement this. If the user opens another instance the contents of what it opened should go to the already opened instance. As an example, I would put emacs. How would I go about coding this? Pipes? Sockets? None of the above. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
On 17.02.2013 16:57, Ian MacArthur wrote: I used named pipes to do this, since they work ok on WIN32 as well as *nix OSX. My app tests for the presence of the named pipe on launch; if not found it launches a full instance creates the pipe... If found, a little helper function just writes the new file instance onto the pipe then terminates. The main app monitors the incoming pipe for actions, albeit as a low priority background thread. Seems to work ok, but was a bit of messing about with platform specific code to get the pipes to work transparently across platforms. There's probably a better way though! Maybe not better, but for some reasons easier to implement, at least for me: I used a local TCP socket and Fl::add_fd() for this. PRO: platform independent implementation, and Fl::add_fd() works even on Windows, where Fl::add_fd() is restricted to sockets. This was the main argument to do it this way. Also, no threads required. CON: you need a fixed local socket number for it to work. A named pipe would be more flexible (arbitrary NAME vs. socket NUMBER). The app first tries to connect to the socket, and if it exists, sends a message and exits. If it doesn't exist, then this is the first instance of the app. It creates a local server socket and registers it with Fl::add_fd() to watch it. Whenever a new app is started, a callback is triggered in the first instance, since the other instance writes to the socket. The first instance then reads the message from the socket... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
How would I go about coding this? Pipes? Sockets? None of the above. AFAIK mutex or semaphore are ment to realise this. Well, maybe not - a lock file (or in my case a named pipe) can be a better bet, since it will work across processes on all platforms, whereas not all hosts systems will support mutexes across processes in that way... This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
On 18.02.2013 11:12, MacArthur, Ian (Selex ES, UK) wrote: There's probably a better way though! Maybe not better, but for some reasons easier to implement, at least for me: I used a local TCP socket and Fl::add_fd() for this. PRO: platform independent implementation, and Fl::add_fd() works even on Windows, where Fl::add_fd() is restricted to sockets. This was the main argument to do it this way. Also, no threads required. Yes: though my code was threaded anyway, so there wasn't a big cost for me in going this way. I knew that, and that's why I wrote at least for me ;-) It would have been nice if Fl::add_fd() worked on pipes on WIN32 though... Yep, and files as well. CON: you need a fixed local socket number for it to work. A named pipe would be more flexible (arbitrary NAME vs. socket NUMBER). Not quite an arbitrary name though - I had to figure out a recipe whereby the new process would figure out the same name as any prior process, so that it could look for the name at runtime... My emphasis was on NAME vs. NUMBER, and what you can select the name|number from. This way, I still consider the selection of a name for a pipe arbitrary, since the name space is much bigger than a number range from 1024 to 65535 for non-priviledged TCP sockets. Of course, all processes must agree about the same name if they want to communicate... I made something up based on user name, the dir in which the executable resided, and, erm, some other stuff... That seems to work, and means that if two users are on the same machine they get one instance each, rather than just one instance between them. Which was what I wanted. Yes, I didn't consider different users on the same system (client PC), since Windows was the main target, and single user Linux workstations were a secondary target. However, if I'd get the task to make it work for different users on the same system, maybe Linux workstations/servers with remote (X) access, then I'd probably utilize Fl_Preferences for saving the socket number (or pipe name, or ...), since Fl_Preferences is user specific. You must still take care that it is unique, and _your_ app probably predates the addition of Fl_Preferences to FLTK, but you know what I mean. For some sort of server process, maybe one instance for all users would be more appropriate, though? Sure, however in my constellation it's a GUI (FLTK) program, and so one instance per user would be the way to go, too, if there could be more than one user on a client PC. It would even be more complicated, if more than one _person_ could access the same system with the same _user_ name from different remote workstations. Not really something you'd want, but in real life ... :-( The app first tries to connect to the socket, and if it exists, sends a message and exits. If it doesn't exist, then this is the first instance of the app. It creates a local server socket and registers it with Fl::add_fd() to watch it. Whenever a new app is started, a callback is triggered in the first instance, since the other instance writes to the socket. The first instance then reads the message from the socket... Yup - sounds familiar... Only I didn't have the convenience of a working Fl::add_fd() method to help out, so I have a helper thread that just blocks on the pipe, and only ever runs if there is something there to read. Same principle, of course... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
Gonzalo Garramuno schrieb: I would like my application to have only one instance of it running at a time. How would I go about coding this? Pipes? Sockets? None of the above. AFAIK mutex or semaphore are ment to realise this. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] OT: Making application run once
I would like my application to have only one instance of it running at a time. However I am unsure how to implement this. If the user opens another instance the contents of what it opened should go to the already opened instance. As an example, I would put emacs. How would I go about coding this? Pipes? Sockets? None of the above. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
Hi, If you are going to run your program on Linux/Unix, you can use DBus and it's feature to assign unique name to connected client; example of this you can find at: http://sundaram.wordpress.com/2010/01/08/single-instance-apps-using-d-bus/ However, if you are thinking to make it OS inferior or simply to omit DBus, you can create hidden so called 'lock' file at known location when application starts (e.g. /tmp/.foo.lock) and delete it when application quits; the same application will check if that file exists and if does, report how one instance is already running. Sanel On Sat, Feb 16, 2013 at 05:10:11AM -0800, Gonzalo Garramuno wrote: I would like my application to have only one instance of it running at a time. However I am unsure how to implement this. If the user opens another instance the contents of what it opened should go to the already opened instance. As an example, I would put emacs. How would I go about coding this? Pipes? Sockets? None of the above. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
Am 16.02.2013 14:10, schrieb Gonzalo Garramuno: I would like my application to have only one instance of it running at a time. However I am unsure how to implement this. If the user opens another instance the contents of what it opened should go to the already opened instance. As an example, I would put emacs. How would I go about coding this? Pipes? Sockets? None of the above. For OS independence I would use: http://www.fltk.org/doc-1.3/classFl__Preferences.html together with repeat_timeout( cb ) it should be fine http://www.fltk.org/doc-1.3/classFl.html#ae5373d1d50c2b0ba38280d78bb6d2628 Application reads the lock key and if none exists, writes a new lock key containing e.g. a PID. Second instance reads the lock key, checks if the PID exists and writes a command key with instructions for the first instance and quits. The first instance polls through repeat_timeout() the command key and does what it needs. On exit the first application deletes the lock key. hope this helps Kai-Uwe ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
On 02/16/13 05:10, Gonzalo Garramuno wrote: I would like my application to have only one instance of it running at a time. However I am unsure how to implement this. If the user opens another instance the contents of what it opened should go to the already opened instance. As an example, I would put emacs. How would I go about coding this? Pipes? Sockets? None of the above. Sniffing around a bit, I believe the terminology to search for is single instance application, and SDI (Single Document Interface), the latter usually using the former. I'm not sure offhand what the 'right approach' is, esp for a cross platform app other than to probably find and use an existing cross platform toolkit that handles this for you. Likely such toolkits use sockets or named pipes. Microsoft has docs on this (I don't necessarily recommend the technique they recommend here, but just FYI to show the terminology they use): http://msdn.microsoft.com/en-us/library/ms996475.aspx#reaworapps1_topic5 Qt has a class to handle this called QtSingleApplication, ie: http://doc.qt.digia.com/solutions/4/qtsingleapplication/qtsingleapplication.html#details ..you might want to look at its innards for implementation, as it likely does what you want cross platform. From what I can tell, there are cross platform toolkits out there already that can implement this for you, but I can't refer to any as I don't know which ones to recommend. Or just roll your own, and create a ~/.yourapp-lock file, and as Kai-Uwe says, either use that file to write commands, or use a named pipe like the lp daemon does, or use a socket. The lock file should have a pid in it (as KU mentions) and info on how to contact it (socket port#, named pipe filename etc) or just make the lock file the named pipe. Both unix and windows support named pipes, and although the APIs are not the same. Some info here: http://en.wikipedia.org/wiki/Named_pipe ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
