Happy new year everyone!
That's the second to last session of the book club.
Just more two chapters to end this book.

Chapter 11

What we know as threads in the UNIX world, in Plan 9 is just a process that shares the memory with another and that is called with the RFMEM flag to rfork(2). What Plan 9 calls thread is a user-space flow of control created and controlled by the process itself. Therefore, the OS does not do any context switch between threads; the program itself must do that.

The chapter begins introducing threads and the difference between threads and light-weight processes (those processes that share memory).

Thread-related routines are provided by the thread library, which also contains the main() routine. We should write threadmain() instead for our main thread.

Then we are introduced to channels, a communication and context-switching mechanism between Plan 9 threads.

One problem with Plan 9 threads is that a blocking operation, such as I/O, blocks the entire process, rather than blocking a single thread. The thread library provides a proccreate(2) routine we can use to create a new thread wrapped in a new process.

To “poll” multiple channels, there's the alts(2) routine, which receives an array of Alt structures containing the channel operations.

The chapter ends with a notice on how to use other routines with the thread library. There are alternatives to exec(2), exits(2), wait(2), and atnotify(2) that are “multi-thread safe” in Plan 9, especially when using threads wrapped inside processes: procexec(2), threadexits(2), threadwaitchan(2), and threadnotify(2).


Chapter 12

The chapter talks about some I/O drivers, such as #c driver (console), #m driver (mouse), and the #v driver (vga). The files provided by those drivers are multiplexed by rio for each window.

It begins by explaining how the #c driver “cooks” the text typed at the keyboard. Things are a bit different in 9front than what is described in the book. In special, reading from '#c/cons' yields:


Asking on #cat-v, I got the following answer:

Quote:basically, devcons no longer does keyboard translation, that's userspace

Runes (unicode characters) can be typed using the compose key, which is related to X11's compose key. There is a handy Compose+X+NNNN key chord for inserting a rune by its unicode codepoint. My X11 also does that (because I listed, by hand, all the possible 2-byte codepoints in my XCompose file. It also talks about the rune(2) routines for handling runes.

One interesting feature of the print(2) function is that we can install verbs (that's how Plan 9 (and golang) calls the printf-like percent formatting directives). See fmtinstall(2).

Now I'm having some xlib vibes by using the draw(2) library: We establish a connection to the draw device, which sets a Display structure that represents such connection. Screen is the “drawable” (or in Plan 9, a pointer to an Image) where we draw on.

The chapter introduces the threaded routines for handling graphical/mouse/keyboard events. There is also an event library for non-threaded programs.