From esandler@usa.net Sat Jan 15 00:41:46 2000 Received: from crcst348.netaddress.usa.net (crcst348.netaddress.usa.net [204.68.23.93]) by spog.gaertner.de (8.8.8/8.8.8/Nase) with SMTP id AAA11905 for <bugs@gaertner.de>; Sat, 15 Jan 2000 00:41:45 +0100 Received: (qmail 5440 invoked from network); 14 Jan 2000 23:41:43 -0000 Received: from nwcst282.netaddress.usa.net (204.68.23.27) by outbound.netaddress.usa.net with SMTP; 14 Jan 2000 23:41:43 -0000 Received: (qmail 5168 invoked by uid 60001); 14 Jan 2000 23:41:43 -0000 Received: from 204.68.23.27 by nwcst282 for [63.23.139.236] via web-mailer(M3.4.0.33) on Fri Jan 14 23:41:43 GMT 2000 Message-Id: <20000114234143.5167.qmail@nwcst282.netaddress.usa.net> Date: 14 Jan 00 16:41:43 MST From: Eric Sandler <esandler@usa.net> To: bugs@gaertner.de Cc: metasoft@home.com Subject: bug >Number: 33 >Category: j-unix >Synopsis: In 16!:20, socket_handler '' doesn't work. >Confidential: no >Severity: critical >Priority: high >Responsible: neitzel >State: closed >Class: mistaken >Submitter-Id: net >Arrival-Date: Sat Jan 15 00:52:02 MET 2000 >Last-Modified: Tue Jan 18 00:52:20 MET 2000 >Originator: Eric Sandler >Organization: MetaSoft Inc. >Release: j 4.02a >Environment: Sun-ultra, Solaris 2.7 >Description: socket_handler event does not work on Solaris, works on NT. >How-To-Repeat: Given open socket 258 (for example) and socket_handler verb defined then, sdasync 258 followed by input to socket 258 from another process does not trigger socket_handler verb to be executed as on NT platform. >Fix: >Audit-Trail: State-Changed-From-To: open-closed State-Changed-By: neitzel State-Changed-When: Mon Jan 17 21:04:18 MET 2000 State-Changed-Why: The "asynch sockets" are specific to Win32. Unfortunately, this is not properly documented. Async sockets are a good idea in the event-driven Windows world, alas, that's not the way it works in Unix. In Unix, program your IO loop using sdselect, or, if that does not give you good control over things, interface to the Unix system call select(2) via 15!:0. Let me know if need more help doing this. At the present, there is no plan to have asynch sockets in J/Unix. The base system simply does not support those. J could theoretically do the select(2) on its own to fake asynch sockets just as J/Windows offers them. The downside of this solution would be that this would be too much in the way of J programmers using select(2) on their own. (Or, more likely, via some other library. The entire X11 libs are essentially select(2)-based, so we have to be very careful not to interfere here.) At any rate, what J does need and *will* get is some means equivalent to signal(3), i.e. handlers for Unix software interrupts. Note that this again would tie in well with socket communications (you can send a "wake up" interrupt along with the data to the peer via a socket). Most communication settings are best implemented with the (sd)select approach, though. >Unformatted: