len@spam.istc.sri.COM (Len Schlegel) (05/15/88)
Forgive me if this question is inappropriate for this group. In unix systems it seems that you can block awaiting input on some socket in two ways. Either you use a blocking socket and then read (or block at a select call) and continue when input arrives, or have your socket set so that a SIGIO is generated when input arrives, at which point you do your read (or select) in your signal handler. The blocking can be achieved by using the sigpause call. In the later case, the socket can be non-blocking. The question is are there performance implications in using one approach over the other. Thanks, Len Schlegel len@spam.istc.sri.com
bzs@bu-cs.bu.EDU (Barry Shein) (05/15/88)
>In unix systems it seems that you can block awaiting input on some socket in >two ways. Either you use a blocking socket and then read (or block at >a select call) and continue when input arrives, or have your >socket set so that a SIGIO is generated when input arrives, at which >point you do your read (or select) in your signal handler. The blocking >can be achieved by using the sigpause call. In the later case, the socket >can be non-blocking. > The question is are there performance implications in using >one approach over the other. You'd probably do well directing questions like this to unix-wizards@sem.brl.mil (I think that's the appropriate host name.) Doing the read alone is clearly lower overhead as the signal mechanism requires several things to happen as well as the ultimate read, you pay what you get for. Whether it's "high" or "unacceptable" overhead is an entirely differnet question and depends on the motivation which brought the question up. If you were doing nothing but looping in data I can't see any reason to incur the signal overhead. If you sometimes needed the non-blocking behavior than you have a reason to do that, etc etc. -Barry Shein, Boston University