Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

inter process communication 1

Status
Not open for further replies.

mastermagrath

Technical User
May 21, 2004
28
0
0
US
Hi,

I was recently guided towards perl/tk for GUI creation but have realised this was only address 1 of my requirements.
I know i'll have to use separate processes but i cant seem to get a good picture as to how i can communicate between them, ideally i'd like a parent process to make a change to a variable which a child process would be constantly monitoring for change and then act upon the change.
Here's the script i want to implement: Hash characters are sent to STDOUT at a particular rate (e.g. i second delay between each), a user can adjust a slider widget to increase or decrease the rate of hashes output without having to stop and start the current output.

If create 2 processes, one for the GUI and one for the hash output how can i communicate the change in slider value to the process with the loop contolling the hash output?
I'm bamboozled by all the different areas that all look like possibilities i.e. pipes, forks, processes, spawns etc. I'd really appreciate some pointers.

Thanks in advance
 
One other note, i thought about having the widget process writing its value to a text file. The hash process could then be written to periodically read this and act upon any change. However this seems to be a bit kludgy? What do you think
 
Your suggestion of a file may be, as you put it, kludgy, but at least you can be sure that the hash output script will always run.
You could try sockets but personally, I think that's overkill.
Shared memory is suggested (in perlipc at least) to be unreliable for sharing data so I guess you're left with semaphores and signals.
Signals are nice and clean and simple but not easy to track.
You could use 1 signal for up and 1 for down to increase and decrease the speed but then you either have no idea of the current speed or you have to deal with the whole issue all over again just to feedback the current speed.
You could have a range of signals, one for each speed I guess but then you're gonna be a bit limited to your total range of available speeds.

My personal favourite is perl threads.
With threads you can setup a process with multiple threads, one for the gui and one for the hash output and you can specify certain data to be shared. I haven't tried this for a long time but I did manage to get some multi-threaded code running beautifully. I can't remember if it needed to share data or not so I guess you can test it and see.
For more info on threads see perlthrtut

Hope that's given you some ideas.


Trojan.
 
Trojan,

Thanks so much for that, my head was starting to spin a bit so its nice to have something specific to look into...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top