Oh wow. I tried J socket programming too a few years back and I had to give up and wrote a server in C++ and eventually C# (windows service programming is now ridiculously easy ... with the distinct disadvantage of not being cross platform though).
One of the things I tried when implementing asynchronous socket in J was to move the response off the process. I mean instead of waiting for the called process to return and having callbacks all over the place, I made all the sub-processes to insert a record in a table in a database and update/remove that record when they are done. The main process will then just "poll" the database table. I remember this working but had to abandon it when I shifted to a Windows service. What I'm saying is that maybe we can setup a "process manager" where sub-processes can register themselves and the master process would just "poll" the status of his own processes. Hmmm. I guess my suggestion would complicate things fast ... but at least its here (written down) and may be considered an option. ________________________________________ From: [email protected] [[email protected]] On Behalf Of Don Guinn [[email protected]] Sent: Wednesday, February 17, 2010 7:29 AM To: Chat forum Subject: Re: [Jchat] Multiple cores OK. Not a line of code. Just a question. Building an application with sockets similar to this several years ago, I had to code a way I don't like. And I was wondering how some of you might have handled it. Since J is non-preemptive and must become idle to process interrupts, Writing code to schedule pieces of the problem to other instances of J, then wait for their completion, is not very pretty. The function that schedules the work and any functions that called it must end so J goes idle. Then, as interrupts come in, a different function, the handler for the interrupts, must pick up, check for all scheduled instances of J have completed, then continue with the problem. If we are using sockets to communicate, then this second function must be socket_handler run in the base locale. I used this approach several years ago and it works fine, but my background in structured programming makes me uncomfortable with it. It's just ugly! This could be simplified by using blocking sockets. When all work is scheduled simply do a sdrecv. Since the socket is blocking, it will hang until data is received. Fine, unless we need to watch for interrupts from several sockets. So it's back to using socket_handler. Thoughts? On Tue, Feb 16, 2010 at 3:05 PM, <[email protected]> wrote: > >I think it would be best to keep the discussion public, because the more > >eyes the better. [...] Does anyone object? > > For "chat", anything goes (and I don't give a damn). > > I *do* object to messages submited to "programming" with lots of > geral statements, handwaving, but not a single line of specific J > _program_ and its possible vectorised/parallised implementation. > > Since my nerves are already worn thin by the "Annoted Dictionary" > mega thread "over there", here a small reminder how the "programming" > forum is defined [on http://jsoftware.com/forums.htm]: > > "programming - the main forum, covering J programming from > beginner to expert, and announcements" > > Repeat: "covering J programming". > > That is NOT: "covering the didactics of J programming". > That is NOT: "covering implementations of J". > > While the latter are certainly worthwile topics, they are just > off-topic noise in "programming". > > Martin > > This message typed on a device with limited tolerances. > Excuse any overly harsh expressions. > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
