perlconcurrency.txt

perlconcurrency
	problem (“two axes”)
		compute-bound problems
			Spread the load
				“embarrassingly parallel” i.e. "divide/conquer"
				"divide/conquer/combine"
		I/O bound communication
			Wait for opportunity to send or receive
				Network
				Disk
				User
				IPC
				Task
	questions
		How do we do more than one thing at once?
		How do we share information between concurrent activities?
	mechanisms
		Concurrent (OS does scheduling)
			Forks
				Pros
					Native to perl (except Windows)
					safe because processes are independent
					good for “divide and conquer”
					fast (COW)
				Cons
					intercommunication hard
					limit to # procs
					Windows portability (“leaky abstraction”)
					limited scaling
			OS threads (non-perl)
				Pros
					multiple points of control with shared access to same mutable state
					higher theoretical performance of intercommunication (but see cons)
				Cons
					have to coordinate access to shared mutable state
			threads.pm
				Pros
					Allows (leaky) fork emulation on Windows
					Potentially portable across systems
				Cons
					heavy/slow wrapper because clones entire VM
						slow to create
						slow because interpreter has to be careful to synchronize
					doesn’t behave like thread from other languages (shared nothing by default)
					thread support is 5-10% slower
		ithreads (Perl does scheduling)
			original threads < 5.8 — ignore
		Multiplexed (user-process does scheduling)
			Non-blocking
				Request action and OS says “ok” or “not now”
				IO::Select, IO::Poll, Epoll, etc.
					Pros
						shallow wrappers around fundamental OS concepts
						low-level, high performance possible
					Cons
						low-level and need to know details to drive them — needs lots of abstraction
						Not necessarily portable (e.g. select on handles on Win32)
			Asynchronous
				Queue desire to do something and you get notified when done
				Event systems (async abstraction on non-blocking mechanism)
					C library wrappers (libev, etc.)
						Pros
							high performance possible
							abstractions built in C
						Cons
							Only as portable as C library
							Don’t always play well with Perl way of doing things
					Perl native
						Pros
							Achieve high level of abstraction from mechanisms of problem
							Potentially portable (depending on underlying mechanism)
						Cons
							Lack of familiarity; idiosyncratic
				AIO aside?
					doesn’t play well with other non-blocking
	Teleological (history/evolution) -- possibly integrate with "mechanisms"
		Forks (“CPU axis”)
			fork(), Parallel::ForkManager, etc.
		Non blocking (“IO axis”)
			IO::Select, etc.
		Superset: event systems (“both axes”)
			“event abstraction”: this happened, that happened
				Glib
			“operation abstraction”: "do operation and report back"
				POE
				AnyEvent
				IO::Async
		Grand trinity
			Timers
			Signals
			File handle IO
	cases
		Axis 1: primarily compute-bound
			Q: “how do I use more of  my CPU cores?”
				need to use multiple processes
				issue is how do I distribute tasks to processes and collect result (if I care)
					Specialized tool: e.g. Parallel::ForkManager, Parallel::Iterator
					General tool: Event system
			Case 1: “embarrassingly parallel”
				eg. thumbnails of a directory of images
			Case 2: “divide/conquer/combine”
				e.g. log file analysis
		primarily IO-bound
			Q: “how can I talk to lots of people at the same time?”
				Can I natively do non-blocking IO in a single process?
					Specialized tool: e.g. HTTP::Async?
					General tool: Event system
				Is it inherently blocking (e.g. getaddrinfo) -- use a separate processes and a coordinating process?
					Use an event system to launch process and get result
			Case 1: “embarrassingly parallel”
				e.g. web serving
			Case 2: “interactive”
				e.g. chat server