DEV Community: Aleksey Reprintsev

My favorite tmux prefix

Aleksey Reprintsev — Wed, 26 Apr 2023 17:20:39 +0000

For a long time I used screen, but now tmux is my favorite terminal multiplexer. But my fingers could not get used to the Ctrl+b combination, so I decided to please them. An internet search revealed that the most popular prefix combinations are Ctrl+a, Ctrl+Space, Backtic, CapsLock followed by many others.

My wishes:

the keys for the prefix were located side by side;
it was not necessary to twist the fingers to press them;
there were two symmetrical combinations for the right and left hand.

The most promising combination at first seemed to be Ctrl+Space, and at first it even seemed convenient, but after experimenting I found it.

So my favorites: Alt+z and Ctrl+/

My usual tmux workflow is: open multiple panes, select a layout, switch between panes, expand/collapse a pane, minimize tmux, expand tmux, detach the session.

LAlt+z, LShift+', LAlt+z, LShift+', RCtrl+/, RAlt+2, LAlt+z z, LAlt+z z , LAlt+🠕, LAlt+🠗, LAlt+z RCtrl+z, fg, RCtrl+z d

Almost like playing the piano :)

Explanation:
(LAlt - left Alt key, LShift - left Shift key, RCtrl - right Ctrl key, RAlt - right Alt key)

LAlt+z, LShift+' # Split the current pane into two, top and bottom
LAlt+z, LShift+' # Split the current pane into two, top and bottom
RCtrl+/, RAlt+2 # Arrange panes even-vertical
LAlt+z z # Zoom current pane
LAlt+z z # Unzoom current pane
LAlt+🠕 # Switch to pane above
LAlt+🠗 # Switch to pane below
LAlt+z RCtrl+z # Suspend the tmux client
fg # Bring tmux to foreground (bash command)
RCtrl+/ d # Detach the current client

Here is my config file

# reload config after changes
# tmux source-file ~/.tmux.conf

# colors
set -g default-terminal "screen-256color"
# set -g default-terminal "tmux-256color"

# prefix keys
unbind C-b
set-option -g prefix C-_                # Ctrl+/
set-option -g prefix2 M-z
bind-key C-_ send-prefix
bind-key M-z send-prefix -2

# mouse mode on
set-option -g mouse on

# key bindings
bind r source-file ~/.tmux.conf         # reload config

# switch panes using Alt-arrow without prefix
bind -n M-Left select-pane -L
bind -n M-Right select-pane -R
bind -n M-Up select-pane -U
bind -n M-Down select-pane -D

I hope this proves useful to someone.

How to limit the number of simultaneously running goroutines and wait for their completion

Aleksey Reprintsev — Sat, 05 Nov 2022 16:17:51 +0000

Launching goroutines
Starting goroutines with a delay in completing main()
Waiting for the completion of all goroutines
Limiting the number of simultaneously running goroutines

Sometimes there is a task to limit the number of simultaneously running goroutines to comply with some limits. For example, by the number of CPU cores or by the memory consumed, etc.

Launching goroutines

To begin with, let's see how to run goroutines. Let's run 5 gorutins in a loop, we simulate the work of the goroutine through time.Sleep(), we will set the delay as i * 100ms. The string i := i is needed to localize the value of the loop counter for iteration, without this, each goroutine will get the value 5. Read more here and here.

package main

import (
    "fmt"
    "time"
)

func main() {
    fmt.Println("START main")
    for i := 0; i < 5; i++ {
        i := i
        go func() {
            delay := time.Millisecond * time.Duration(100*(i+1))
            fmt.Printf("  START #%d (delay %v)\n", i, delay)
            time.Sleep(delay)
            fmt.Printf("  END #%d (delay %v)\n", i, delay)
        }()
    }
    fmt.Println("END main")
}

Output:

START main
END main

Program exited.

Playground

It follows from the output of the program that not a single goroutine was executed. This happened because the execution of the program (function main()) ended immediately after the completion of the for loop, so all running goroutines were also completed almost immediately after their execution began.

Starting goroutines with a delay in completing `main()`

Let's see what happens if some delay is introduced before the program ends, for example 250ms.

package main

import (
    "fmt"
    "time"
)

func main() {
    fmt.Println("START main")
    for i := 0; i < 5; i++ {
        i := i
        go func() {
            delay := time.Millisecond * time.Duration(100*(i+1))
            fmt.Printf("  START #%d (delay %v)\n", i, delay)
            time.Sleep(delay)
            fmt.Printf("  END #%d (delay %v)\n", i, delay)
        }()
    }
    // Let's add some delay
    time.Sleep(time.Millisecond * 250)
    fmt.Println("END main")
}

Output:

START main
  START #4 (delay 500ms)
  START #0 (delay 100ms)
  START #1 (delay 200ms)
  START #2 (delay 300ms)
  START #3 (delay 400ms)
  END #0 (delay 100ms)
  END #1 (delay 200ms)
END main

Program exited.

Playground

As you can see, after adding a delay to the main() function, two goroutines (with duration of 100ms and 200ms) managed to be executed. If the delay is increased to 500ms or more, then all the goroutines will have time to be executed.

Waiting for the completion of all goroutines

In real life, it is rarely possible to determine the execution time of goroutines, therefore, to wait for the completion of all goroutines, you can use WaitGroup from the sync module. From documentation module:

A WaitGroup waits for a collection of goroutines to finish. The main goroutine calls Add to set the number of goroutines to wait for. Then each of the goroutines runs and calls Done when finished. At the same time, Wait can be used to block until all goroutines have finished.

In our example, we will call Add(1) before each start of the goroutine, and Done() when the goroutine is completed via defer.

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    fmt.Println("START main")
    var wg sync.WaitGroup
    for i := 0; i < 5; i++ {
        i := i
        wg.Add(1)
        go func() {
            defer wg.Done()
            delay := time.Millisecond * time.Duration(100*(i+1))
            fmt.Printf("  START #%d (delay %v)\n", i, delay)
            time.Sleep(delay)
            fmt.Printf("  END #%d (delay %v)\n", i, delay)
        }()
    }
    wg.Wait()
    fmt.Println("END main")
}

Output:

START main
  START #4 (delay 500ms)
  START #2 (delay 300ms)
  START #3 (delay 400ms)
  START #1 (delay 200ms)
  START #0 (delay 100ms)
  END #0 (delay 100ms)
  END #1 (delay 200ms)
  END #2 (delay 300ms)
  END #3 (delay 400ms)
  END #4 (delay 500ms)
END main

Program exited.

Playground

We see that all the goroutines have time to complete, but the problem of simultaneous launch of all goroutines has not yet been solved.

Limiting the number of simultaneously running goroutines

To limit the number of simultaneously running goroutines, a buffered channel can be used. The feature of the buffered channel is that after the buffer is filled, the next write to the channel is blocked until at least one value is read from the channel.

The constant grMax contains the number of simultaneously executed goroutines. After the channel buffer is full, execution will be blocked on the command ch <- 1 and will continue after reading from it with the command <-ch. It is better to place the command to read from the channel in defer so that when errors occur in the gorutin, the entire program does not hang.

package main

import (
    "fmt"
    "sync"
    "time"
)

const grMax = 3

func main() {
    fmt.Println("START main")
    var wg sync.WaitGroup
    ch := make(chan int, grMax)
    for i := 0; i < 5; i++ {
        i := i
        wg.Add(1)
        ch <- 1
        go func() {
            defer func() { wg.Done(); <-ch }()
            delay := time.Millisecond * time.Duration(100*(i+1))
            fmt.Printf("  START #%d (delay %v)\n", i, delay)
            time.Sleep(delay)
            fmt.Printf("  END #%d (delay %v)\n", i, delay)
        }()
    }
    wg.Wait()
    fmt.Println("END main")
}

Output:

START main
  START #2 (delay 300ms)
  START #0 (delay 100ms)
  START #1 (delay 200ms)
  END #0 (delay 100ms)
  START #3 (delay 400ms)
  END #1 (delay 200ms)
  START #4 (delay 500ms)
  END #2 (delay 300ms)
  END #3 (delay 400ms)
  END #4 (delay 500ms)
END main

Program exited.

Playground

As you can see, 3 goroutines were immediately launched #0, #1, #2, then, after completing one of them (#0), the next one is started (#3) and so on.

The problem is solved.

Low performance of Ruby on Rails in Docker under Windows

Aleksey Reprintsev — Sun, 12 Dec 2021 09:52:05 +0000

You can improve the performance of Ruby on Rails in Docker under Windows 10 if you run docker-compose not from Windows, but from WSL.

For example, if the source code of the project is in C:\Users\user\projects\myproject, you need to copy it to WSL - /home/user/projects/myproject

The WSL file system from under Windows is accessible via \\wsl$, you can copy myproject via File Explorer or terminal from C:\Users\user\projects\myproject to \\wsl$\Ubuntu-20.04\home\user\projects\

Then, using your favorite distribution, run WSL, go to the directory with the copied code and run docker-compose

cd ~/projects/myproject
docker-compose up -d

To edit code from Windows, you can open the \\wsl$\Ubuntu-20.04\home\user\projects\myproject directory in your favorite editor

In my case, the rendering speed has increased by about 10 times.

DEV Community: Aleksey Reprintsev

My favorite tmux prefix

How to limit the number of simultaneously running goroutines and wait for their completion

Table Of Contents

Launching goroutines

Starting goroutines with a delay in completing main()

Waiting for the completion of all goroutines

Limiting the number of simultaneously running goroutines

Low performance of Ruby on Rails in Docker under Windows

Starting goroutines with a delay in completing `main()`