thanks Bill. but why is it so inadvisable? I don't get it. I'd have thought that some app where you want one task to execute periodically while another responds to user input was exactly where you should use threads. (I'll look into your suggestions though.)
It seems to be some weirdness in dealing with a socket very differently to other file handles eg STDOUT. Can anyone explain what's going on underneath this? BTW I also posted this to perl monks: http://www.perlmonks.org/?node_id=580907 thanks On 10/27/06, $Bill Luebkert <[EMAIL PROTECTED]> wrote: > Daniel McBrearty wrote: > > > Now I want to run a thread inside this app that sends back info > > regularly. It needs to run in a seperate thread, and be startable and > > stoppable, which I have working. I don't care if the responses from > > the main thread and the reporter thread lines are mixed up ... ie > > I would avoid trying to do this with threads. You can handle it > all from a single thread using IO::Select::can_read to handle any > pending inbound socket traffic and can_write to make sure a write > won't block (or you can use non-blocking IO). Use sysread/write > to do the actual IO. I can't think of any reason to use threads > to do this on Win32 - you're asking for trouble. If you insist > on using threads, do as previously suggested and do all of the > socket processing in one thread. > > -- Daniel McBrearty email : danielmcbrearty at gmail.com www.engoi.com : the multi - language vocab trainer BTW : 0873928131 _______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
