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 [email protected] http://lists.easysw.com/mailman/listinfo/fltk
