Need to create a SCSI monitoring child process.

[LivingDust]

Update:

I found a solution to my problem through the use of the Tk method of ->repeat(ms, callback). Instead of forking a subroutine to continuously query the SCSI bus with a sleep/wait repeat, I can call it from Tk, and it seems to work quite nicely.

I also wrote some of the things I learned about threads and Tk and IPC in a comment below.

Dear Monks,

I am trying to set up a perl program that uses tk and in the main window would display of the state of devices attached to the SCSI bus, and allow the user to execute commands relevant to the devices in the SCSI bus.

My thought is to run a parallel subroutine that will continuously monitor the SCSI bus and detect the presence hot-swappable devices. I would want this subroutine to monitor a state variable in the main process with these three states: RUN, PAUSE, and EXIT.

I want the child to update an array of hash information also in the parent process. This array primarily indicates whether a swappable drive is present and some status information if it is.

My question is, how should I start this monitor subroutine, and how can this monitor update some main::variables that my Tk window is also monitoring to have a real-time effect?

I have seen some examples of Parallel:Fork, but nothing that has this level of real-time communication.

Also if the parent dies, I would like the monitor to exit as well.

[dd-b]

Well, you can't do it by directly accessing the main memory from a forked process in Perl; the fork call doc makes that pretty clear.

You need some form of IPC mechanism, so perlipc is a useful place to look. Maybe semaphores, or a shared file, or something.

[LivingDust]

The problem with a shared file is I would still need a parallel routine running to check the contents of the shared file. What I want is to write something that checks the status of the SCSI bus every 15 seconds or so and updates some variables, but does not block my main program.

[McA]

Hi,

what does blocking mean in your context?

Let's asume the following: You have a child process which scans the scsi bus regularly (e.g. lsscsi) and puts this information into a array of hashes which gets serialized into a file (real file on the file system or shared memory segment). The main program (tk) would try to get a read lock on that file. If it doesn't get it, it continues the event loop (showing the probably old information). If it gets the lock than it reads the information (which should be fast either on a real file or shared memeory (which should be faster)) and diplays it.

Assumimg communication is done via shared memory, I would expect that the interchange of information between the two processes (gathering information about scsi and reading this information) is done quikly and therefore more or less without blocking.

Best regards
McA

[LivingDust]

In exploring solutions to my problem, I have discovered / learned a few things.

1) Tk is not thread safe. Forked or threaded processes cannot interact with Tk widgets.

2) IPC::Shareable was what I needed to share variables between separate processes. However the act of making it shareable seems to alter the references in such a way that I could not use the elements of my hash within an array as -textvariables.

3) I DON"T NEED A SEPARATE PROCESS AT ALL!

It turns out I can use the

$mw->repeat(100, \&subroutine)

quite effectively to issue commands to check the status of the SCSI bus. So my program is rocking quite nicely now.