Front page | perl.perl5.porters |
Postings from January 2001
Dan Sugalski wrote: > >Roll on perl6... > > Well, besides "Just don't *do* that," any thoughts on how to handle this > properly in p6? Hmm. I've been half-following the async IO and signals thread in perl6-internals. The first thing I would say is that if you think there are portability problems with threads and signals, wait until you get to play with cross-platform AIO. General received wisdom seems to be that using multiple threads and synchronous IO is a much easier thing to get working than trying to use the various difficult-to-use AIO APIs. That leads nicely onto the next point - signals. Again, the received wisdom here is that if you are going to use threads and signals together, you should have a dedicated signal handling thread which does a sigwait and sets a flag when a signal occurs. The flag would be polled by the main loop and the signal handler called when it was safe to do so. Now I can see that at this point all you speed freaks want jump on me and tell me how horribly inefficient this additional test would be. I have only one thing to say to you - get real. One conditional (even if protected by a mutex) is neither here nor there when compared to the number of instructions taken to implement a typical perl op, and you wouldn't do it for every op dispatched anyway. A sensible thing might to be to get the compiler to emit statement boundary markers into its output, and use these as points at which you check for and dispatch signals. For example, on my platform (sparc), an empty for loop takes about 10 cycles per iteration, a function call to setjmp takes about 10 cycles and a call to sigsetjmp takes more than 5300 cycles, due largely to the fact that it requires a syscall and is therefore also an invitation to the OS to reschedule your process. If you want to worry about something, worry about that 5300 cycles first. Then worry even more that setjmp isn't thread safe either. The upshot of all this is I think perl6 should be mandatorally threaded, with a mixture of internal threads (signal handler, async IO handler, garbage collector, whatever), and application threads. Each application thread would be an entire instance of the interpreter - none of that crazy mutex madness that doomed the attempt to thread perl5. Interpreter threads would touch at well-defined points only - the aim being to avoid mutexes as far as possible, rather than to infect everything with them. In the degenerate case (existing unthreaded scripts) there would be only one interpreter instance and therefore only one application thread. This has lots of advantages - no changes in behaviour when threads are used as perl is always threaded, well-defined semantics of how multiple interpreters coexist and cooperate, system housekeeping can be modularised and done behind the scenes in dedicated threads etc etc. The downside is that we would restrict perl6 to only those platform that supported threads. I'm not sure how much of a restriction this would turn out to be in practice - how many current perl platforms don't have threads? As for AIO - my guess is that faking it up with threads is a much better bet. After all, what proportion of apps are MT vs AIO, and which is most likely to be available, well tested and well supported? Alan BurlisonThread Previous | Thread Next