On Mon, Jul 15, 2013 at 4:01 PM, I.T. Daniher <[email protected]> wrote: >> sdasync=: 3 : 0"0 >> if. IFUNIX do. 'not implemented under Unix - please use sdselect' assert > 0 end. > ... > > It looks suspiciously like there's no support for asynchronous sockets in J > in Linux. Is this the case? Is there a workaround?
We could think of the GPLing of J's source as a workaround. Though, properly speaking, the workaround might need to go into jconsole, not J proper. (Not strictly true - see below.) Here's the design I am thinking of: Rebuild J's main loop using select (or "poll"). Build an async callback mechanism to plug into this aspect of the main loop. Here's why this mechanism does not strictly need to belong in jconsole (and, especially for an initial model, should not go into jconsole): You can take over the main loop at any time by building your own main loop and not returning to the "real one". [This introduces a conflict, anything plugged into the real main loop will be locked out, and given our current lack of anything approaching a source code documentaton community we cannot sustain too many such conflicts. But conflicts of this nature can be used to drive further implementation work or documentation or can simply fragment the community. It's up to you how you play it.] Anyways, basically you wind up keeping track of the file descriptors you care about (because those are the ones that you tell select to wait on for read/write/exception conditions) and along with each file descriptor you have some data which identifies a callback mechanism or a standard handling mechanism. Then, when you get activity you do something like ask each of these mechanisms to do something. This is not a particularly elaborate state machine and probably the biggest risk would be the temptation to overdesign or overgeneralize it. You mostly just need enough for async emulation. The painful part might be supporting J's existing IDE's. To get them totally right you need a way of identifying the file descriptors relevant for jhs/jqt/... and they are not going to want to give up control. Qt, especially, is all about being an "integrated system" so you may have to do some searching to find out how to differentiate it. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
