Re: Python from Perl, Perl/Win from Perl/*nix

Mount the Windows box's disk on the unix box and use CIFS (samba) and the filesystem to communicate between the two. Have a driver program on the windows box that looks in an "inbox" folder for new stuff to do. This driver program would be the windows equivalent of a daemon--always running. When it sees files in the inbox, it processes them (by running the specialized software) and puts the result in an "outbox" folder. Also, have a program on the unix box watch the outbox and do whatever is appropriate to the files that show up there.

duff

Comment on Re: Python from Perl, Perl/Win from Perl/*nix

Replies are listed 'Best First'.
Re^2: Python from Perl, Perl/Win from Perl/*nix by Tanktalus (Canon) on Nov 09, 2005 at 19:48 UTC
I have always felt that polling ("pull") solutions a last resort whenever a semaphore or other message system ("push") solution can be used. Pull solutions pretty much always use up more CPU time and RAM as you have to be always running, looking for something periodically. Conversely, a push solution means we only load what we need to load, when it is demanded of us, and we use literally no CPU time until that time. Thus, I much more liked the ssh solution above than using a disk like this. If you are going to write a daemon anyway, have it listen on a port, and wait for communication on that port. Then it can do stuff based on what it receives there. This will mean more RAM used (but it can be swapped out if it's not active very much), but no CPU time (the OS will leave your app asleep until something comes in on the designated port). Especially in perl - perl makes writing client/server TCP apps very easy, not like C. So take advantage of that.	[reply]

Replies are listed 'Best First'.

Re^2: Python from Perl, Perl/Win from Perl/*nix
by Tanktalus (Canon) on Nov 09, 2005 at 19:48 UTC

I have always felt that polling ("pull") solutions a last resort whenever a semaphore or other message system ("push") solution can be used. Pull solutions pretty much always use up more CPU time and RAM as you have to be always running, looking for something periodically. Conversely, a push solution means we only load what we need to load, when it is demanded of us, and we use literally no CPU time until that time.

Thus, I much more liked the ssh solution above than using a disk like this. If you are going to write a daemon anyway, have it listen on a port, and wait for communication on that port. Then it can do stuff based on what it receives there. This will mean more RAM used (but it can be swapped out if it's not active very much), but no CPU time (the OS will leave your app asleep until something comes in on the designated port). Especially in perl - perl makes writing client/server TCP apps very easy, not like C. So take advantage of that.

[reply]