in reply to Re: IO::Select question
in thread IO::Select question

Ok, I've read a little more now today, and your explanation seems to go against the purpose of IO::Select. I thought it was supposed to help you to only bother reading from a particular handle if there was something to read on that handle? Is that not right?

Anyway, the bi directional client server application I want to write should not be affected by this question I know realize, because I'm the one writing both sides, and I'll just aways send a whole line at a time. Not just a few chars, which is what I was worried about happeneing and then causinng my ($line = <$handle>) to just sit there.

Thanks for the feedback though! I'd be interested to hear what your thoughts are on if this is really how IO::select works.

Replies are listed 'Best First'.
Re: Re: Re: IO::Select question
by castaway (Parson) on Jan 21, 2003 at 17:45 UTC
    I won't pretend to know why it actually does that, maybe someone can answer that (it surprised me at the time too). It does only do it for STDIN as far as I can see, Sockets work exactly as you would expect (really waits until the other side sends some data).
    So maybe it's something to do with a special case for STDIN..

    C.

      One more question (maybe should be a new thread). For bidirectional, do I need to use two sockets? Or can the client and server both talk and listen on one socket (as long as they know who is talking and who is listening of course!).

      Thanks! J

        Actually, it's quite funny. I'm working on the exact same project right now. I'm using a combination of IO::Socket and IO::Select and it's starting to work quite nicely. To answer your question, you only need one socket: there is no reason for two different connections (ie: all the data can be sent through one numbered port), though both the client and server apps need to listen to the port.

        As soon as I've got something significantly better than it is now, I'll be sure to post it somewhere and I'll /msg you the link