[EMAIL PROTECTED] wrote: > Uhhh.... I can't believe I just posted it non-list again. Here it is > for the list: >
:-) > On 7/8/05, Wiggins d'Anconia <[EMAIL PROTECTED]> wrote: > >>Please group reply to prevent getting accidentally ignored and so >>everyone can help and be helped. Also please bottom post. > > > Whoops - sorry about that - Gmail must have picked your email address > instead of the list when I hit the reply button. > > > >>Though it is more of a server rather than client example. Essentially >>you open the filehandles (sockets) you want to read from, add them to an >>IO::Select object, then ask that object for a list of handles ready to >>be read from. Then just read from the handle. On the same token you >>should really be using IO::Socket::* instead of messing with the sockets >>directly. > > > Aha - I must have confused it with some other select - I thought > select() just selected which socket is the default. > Just a comment for the archives, and to any other beginner to the Perl docs. Some functions in Perl act differently in different situations, depending either on context or surrounding code. C<select> is a perfect example. When you look at the perldoc for select, perldoc -f select, you will see that there are two distinct sections and ways to write a call to select. Indicated by: select FILEHANDLE select .... select RBITS,WBITS,EBITS,TIMEOUT .... So in this particular case there is what is known as the 1 argument form and the 4 argument form of select. The first version is the commonly used form that returns (and optionally sets) the current default filehandle. Shown as either plain 'select' with no argument (whereby I suspect perl really looks at this as 1 argument where the default filehandle is used) or select with a filehandle. The second version, the 4 argument form, is infrequently used (relatively) and calls the select system call. For the details read the man pages... My point is that when reading the perl documentation you need to pay particular attention to the "header" or "syntax annotation" to understand the context in which the function, et al, can and should be used. Three other important examples include C<map>, C<grep>, and C<eval>. perldoc -f map perldoc -f grep perldoc -f eval Notice for the first two the difference between 'map/grep BLOCK' and 'map/grep EXPR', especially note the comma in the second. There are a number of other examples, but hopefully you get the idea. > >>If it is good enough for Mr. Stein, it is good enough for >>*almost* all of us. > > > Mr Stein? > He is author/maintainer of *just* a couple of the frequently used CPAN modules, you know like CGI.pm ;-). Major contributor to the bioperl efforts, wrote Network Programming with Perl as well as co-authored Writing Apache Modules with Perl, among others. http://stein.cshl.org/~lstein/ > >>On the same token you >>should really be using IO::Socket::* instead of messing with the sockets >>directly. > > > Umm... I am using IO::Socket::INET > Good! I just meant avoid using the "Low-level socket functions" directly... perldoc perlfunc. > >>Having said all of this, it still isn't truly multitasking because you >>can still block on a socket that had a lot of data or a slow socket. >>This method presumes that your CPU and IO handler is fast enough to >>prevent the appearance of a slow down because of blocking. > > > Well, I wasn't really worried about slowdowns, but a blocking socket > would be a real problem with my application - One channel could be > sending lots and lots of messages, which wouldn't be relayed because > the program is busy blocking on the other socket. > Right... which is where select comes in, in whatever form you choose to use it. > >>perldoc -f select >> >>Good luck, > > > Thanks - I just looked at the website you pointed to - it looks > perfect for what I need. The server code example is amazingly clean, > simple and elegent - I will certainly use this for all multi-socket > apps in future > Glad to hear it makes sense and should fit the bill. It will certainly save your hair, assuming you started with any :-).... http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
