On 8 Sep 2009, at 9:20 am, Antonio Vieiro wrote: > "Proc should not mutate any of the lists. The map procedure applies > proc element-wise to the elements of the lists and returns a list of > the results, in order. Proc is always called in the same dynamic > environment as map itself. The order in which proc is applied to the > elementsof the lists is unspecified." > > The report should emphasize that "proc" should have no side effects > (not just on the lists, but everywyhere). It should not impose a > concurrent evaluation, just specify if concurrent evaluation of map > is allowed or not.
Aye. IMHO, a good approach to apply to standardising this sort of situation is thus: "Will a change of wording in this spec make no meaningful difference to non-parallel implementations, but make life a lot easier for parallel implementations?" If that's the case, there's little to lose! > Finally, explicit parallel Scheme is, in my opinion, the *wrong* way > to go (as explicit memory management is, for instance). > Understanding explicit parallel programs (either in Scheme or any > other language) is usually difficult. Debugging and maintaining them > is usually the worst nightmare of a developer. (I can't imagine > debugging a Scheme program with threads, semaphores, locks, and > continuations all messed up). Yeah. Sometimes, you need threads; the case that comes to mind is a server that handles lots of connections initiated by clients we have no control over. If the protocol has any connection state, it's nice to model that with flow control by having a thread per connection. Of course, many high performance servers these days do magic with few threads and non-blocking I/O to multiplex stuff; at a terrible cost in ease of understanding their code, which has to be recast as a state machine so the flow of control can be abstracted out. I'd much rather my Scheme threading implementation handled that for me, implementing threads with continuations, and then ideally forking off multiple actual processes to gain access to multiple CPUs. I'm all for banning the sharing of mutable state between threads; let them use an explicit mailbox protocol. Erlang FTW. But often, you don't need threads. Look at what Apple have been doing recently with Grand Central Dispatch (http://en.wikipedia.org/wiki/Grand_Central_Dispatch ); rather than dealing with threads, I'd much rather submit work that happens somewhere in thread pools. And rather than having to explicitly manage queues, I'd like to do it with map! At a slightly lower level, it'd be nice to have an "eager delay" that produces a promise that runs in the background (by being submitted to a job scheduler, rather than an explicit thread forked), with those who force the promise being made to wait if the answer's not ready yet. The fun part is managing prioritisation in these queues. Obviously, we want things to have a default priority by default, and for child jobs made via large maps and eager delays and even application argument parallelism inherit the parent job's priority; but perhaps we can add (get-job-priority), (call-with-job-priority N THUNK), and (with-job- priority N BODY...) in a suitable "advanced threading" SRFI/library. > > Cheers, > Antonio > ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
