Re: External controlling of a multi-threaded Windows perl program

My suggestion is to let your program listen at a socket or TCP port, so you can completely decouple the control process from the front end, and then perhaps provide a command line and/or a GUI front end.

That way it might a little bit harder, but you can debug front end and backend separately, and you greatly simplify unit testing.

Comment on Re: External controlling of a multi-threaded Windows perl program

Replies are listed 'Best First'.
Re^2: External controlling of a multi-threaded Windows perl program by weismat (Friar) on Nov 05, 2007 at 12:37 UTC
I have decided to go this route. When assuming that there is only one client for the program, then things are relatively easy. The unit testing part is important. I could not really use Windows signals as I need at least two signals. I remember catching Ctrl+C under Windows a long time ago, but I think there was an issue with threads then.	[reply]