I was hoping it might work out like that - in any case, it seems fine for what I've done so far.
On Wed, Mar 17, 2010 at 11:08 AM, Don Guinn <[email protected]> wrote: > For debugging I have used fwrite to write to a trace file but not > explicitly > opening and closing the file. So J opens, writes and closes for each line > written. I have written to that same file from multiple instances of J > which > were all writing to this file essentially at the same time. So far they > haven't stepped on each other. All the messages seem to be there. Doesn't > seem to be too slow either. This is under Windows VISTA with a dual core > processor. > > On Wed, Mar 17, 2010 at 8:51 AM, Devon McCormick <[email protected]> > wrote: > > > These seem like some of the same issues I'm seeing with my simple > > multi-core > > app: now that I start separate, independent jobs to do the work, it's > more > > complicated to time the task than when it was single-threaded within the > > main session. My quick-and-dirty solution was to have each task log its > > start, finish and elapsed times to a common file but this raises the > issues > > you're talking about here: how do I know when I'm done from the point of > > view of the dispatcher? Also, I may now have a rare, output file > > contention > > bug just waiting to bite me. > > > > On Wed, Mar 17, 2010 at 10:31 AM, Don Guinn <[email protected]> wrote: > > > > > I didn't want to get into the more sticky issues as I just wanted to > get > > > across the idea of being able to schedule work and wait on it without > > > having > > > to let J go to idle. As to handling your concerns, wait could have an > > > optional count of semaphores to be set before it ends. Then looking at > > > which > > > semaphores are set tells which statements have completed. > > > > > > What got me thinking along this line was when I saw the first cut of > J7. > > > When jfe handles input and output, J is idle. Or is it? All kinds of > > > possibilities are opened up when I can write J statements that execute > > when > > > J thinks it is idle. And that brings up a number of questions in my > mind > > > with J7. If I have an error in the jfe code, where does it go? What > does > > > the > > > 13!:1'' output look like? If I signal a break, where does it go? How > can > > I > > > use sockets if jfe uses sockets? But now I'm rambling. > > > > > > On Wed, Mar 17, 2010 at 7:32 AM, Robert Bernecky < > > [email protected] > > > > > > > wrote: > > > > > > > I've been contemplating introducing something similar into the APEX > > > > compiler: basically, it's a variant on the rank conjunction. > > > > Effectively, we have what might be considered an array of gerunds, > > > > which we apply, rank-like, to some data. > > > > > > > > The difference is that, unlike rank, we don't wait until all the > > > > execution threads complete, and then laminate the results. > > > > Instead, execution terminates when ANY thread completes, and > > > > that becomes the result. At least, that's the rough idea. > > > > > > > > There are, as usual, some rough edges: > > > > > > > > a. What if more than one thread completes at the same time, as > > > > might happen if we were, say, waiting for several sockets > > > > to change state, or if multiple chessboard evaluations completed > > > > at once? > > > > > > > > b. How do we identify which thread(s) completed? One way, of course, > > > > would be to append, either tacitly or explicitly, the thread's > > > > index/indices into the argument array. > > > > > > > > > > > > Bob > > > > > > > > Don Guinn wrote: > > > > > > > >> . . . > > > >> > > > >> > > > >> I would like to write something like: > > > >> > > > >> rotatepicture=:3 : 0 > > > >> '(rotate fread y)fwrite y' startcore y > > > >> ) > > > >> > > > >> events=:rotatepicture each {."1 fdir '*.jpg' > > > >> wait events > > > >> > > > >> where startcore schedules the statement to be run and returns a > > > semaphore > > > >> that is set when the statement completes. Then wait hangs until all > > the > > > >> semaphores are set. Can't do that in J. Or can we? > > > >> > > > > > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > > > > > > -- > > Devon McCormick, CFA > > ^me^ at acm. > > org is my > > preferred e-mail > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
