> > > My primary problem is that the Sage subprocess is blocking forever on > > the other side of the pipe when its not computing... Therefore, I > > can't have a Sage sub-process that I'm using in the notebook that is > > also able to communicate with other processes as I can't > > asynchronously receive data (or get timing interrupts). I've gotten > > around this in the past by using threads as it was the only choice I > > had. > > Thanks for the clarification. Since I don't really understand the > problem, without further clarification I don't think it will get fixed > in the near future.
Basically, the problem is that the Sage sub-process loses control when its done servicing a request from the server. Instead of entering an event loop, it blocks on the pipe. The alternative would be to return after any request to an event loop. Clearly, the primary requestor would be the notebook server, but if you had a general event loop, the user could register any number of other asynchronous sources or timers to respond to. The adjustment I propose is in the sub-process (and probably would extend this to the notebook but I'll withhold that for the time being). Instead of initializing and entering the read-process-write cycle, where read blocks waiting for a request, the sub-process would initialize, register a callback to handle requests from the server pipe, and enter the event loop. When a request came in, the primary sage callback would "do the right thing" and return the result, hence returning to the event loop. Now, if a user wanted to handle other events or timers, they would simply add those asynchronous systems to the event loop using whatever means were provided. This is, essentially, the purpose of the Twisted Reactor. This sub-process adjustment could (maybe) be done initially without changing anything on the notebook itself. The pipe callback would receive the string, call a slightly modified sub-process method, get the result and return it. Even if there are pexpect elements in the sub-process, the callback could feed that. Of course, once you put an event loop in the sub-process, much of pexpect probably becomes unnecessary. Seems to me that Twisted could do the spawning of the twisted sub-process and just shuffle strings across. I don't really know pexpect but my guess is the things it handles are also handled by twisted (although I don't actually know). Its doubtful that there is sufficient complexity that pickle couldn't handle the marshalling of data across the pipe. Once this change was made, you'd have a full infrastructure with which to build much more flexible applications yet still have the notebook interface. This would also facilitate building distributed computation engines, data collectors etc. Furthermore, as things evolved, truly dynamic AJAX could be built because the underlying Sage process could be asynchronously receiving data, talking with other Sage processes, periodically polling other servers (e.g. yahoo finance) It seems this would be a fairly easy task and have substantial payoff. I would have done it myself, but got bogged down when looking through the pexpect code and the strings shoved over the pipe. I figured that a few hours with the author would save a lot of time but the runaway stack interfered. -glenn > > William > > > > > > > -glenn > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
