> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of zentara > Sent: Tuesday, June 19, 2007 2:55 PM > To: beginners@perl.org > Subject: Re: Inter-thread communications > > On Mon, 18 Jun 2007 12:58:31 -0400, [EMAIL PROTECTED] ("Bob McConnell") > wrote: > > >I have two questions about this. First, is there a standard Perl IPC > >interface between threads? I am not familiar with pipes in > this context, > >although I have used mailboxes and single word messages in various > >multi-processing environments, including POSIX threads. > > This is a big topic, so I'll briefly try to bring you up to speed. > > I'm assuming you are talking about threads in the pure sense, > as opposed > to calling separate processes "threads". ( It's further confused by > MSWindows, emulating fork with threads). > > There are totally independent processes, for which you can do IPC with > pipes, sockets, shared memory segments, etc. > > Threads are different. > Threads are sort of concurrent code which can all run under the same > parent pid. If one thread exits, the whole thread system will die. So > care must be taken. However, you can easily share scalar data between > running threads, and this is their advantage. > > So the standard Perl IPC interface for threads, is shared variables: > see "perldoc threads::shared". Also to be > happy with threads under Perl, you need a version greater than 5.8 > Perl5.6 uses an obsolete thread version which will give you trouble. > > If you are not specifically interested in perl threads, you > may want to > read "perldoc perlipc". The things mentioned in perlipc, are the > original methods of ipc, before threads came along (only recently). > > There are 2 things threads can do for you. > 1. Share variables in realtime between threads. > 2. Share filehandles between threads, by passing their fileno > thru the shared variable mechanism. > > The problem is that one thread will not know if another thread has > changed a shared variable, so you either need an event-loop system, > or a complex while() loop to constantly monitor the values of > the shared > variables. > > The typical setup is a main thread which has an event loop (Tk, POE, > Glib, etc), and as many worker threads as you want. The worker threads > will do things and set shared variables, and the main thread will > monitor the value of the shared vars and do what is needed. > > The main thread will also clean up the worker threads at program end. > > > > >Second, is there a way to set this up so the transmit thread > timeout can > >be easily implemented as a side effect of waiting for the ACK/NAK to > >arrive on that interface? I was thinking of using a > semaphore, but they > >don't appear to be implemented on Win32. > > Yeah, it depends on how your code is written, but you can setup many > timers in an event-loop system to time out something. > Warning.... alarm > does not work well in threads, you need timers. > > See how GLib can help > http://perlmonks.org?node_id=538341 > > Also there is POE, and (Tk and Gtk2 if you want a GUI). > > > > >For this emulation, the outgoing messages are read from a > text file and > >the incoming messages are stored in another text file. Timing of > >outgoing messages is controlled when that file is read. I am > hoping this > >can provide a workaround for the alarm failure I ran into on > the single > >threaded version as well as being a better emulation of the actual > >system. > > > I run linux, so there may be win32 problems that I'm unfamiliar with, > but all of it seems feasible. > > It seems that once the serial port connection is established, and you > have the filehandle, you could have a main thread to control, and 2 > worker threads, one to send, and one to receive. You would setup > some shared variables, like "$ack_received" , etc., and share > the fileno > of the port filehandle between the threads. > Then again, with a proper IO::Select setup, you may not need threads > at all. > > You might want to ask this on http://perlmonks.org > A few monks there are good with win32, and Win32::SerialPort. > If you could show some pseudo-code it would be helpful to them. > > Goodluck, > zentara
I have been trying to implement this in ActivePerl 5.8.8.820 on W2K, so I am working in the thread based fork() implementation. IPC does not seem to exist in that implementation. I had pretty much figured out that alarm doesn't work in Win32. I had tried to use it to interrupt read() on a serial port, and that wasn't working. Neither did SIGINT or SIGTERM. The only way to get out of it was Ctrl->Break, which shuts down the whole process. Unless the Glib timer can interrupt a serial port read() call, I don't see any way to timeout a serial port input function on Win32. Unfortunately, that means I will probably need to steal one of the FC5 boxes from the next room in order to get it to work. Thank you, Bob McConnell -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
