Mirror of forum.nim-lang.org

13325 :: How to deal with blocking operation when using mummy and postgres (db_connector)

• Cnerd (orginal) [2025-08-16T23:57:33+02:00] view original

  What are advice for dealing with the blocking nature of nim postgres db_connector when using a web framework like mummy.

---

• Araq (orginal) [2025-08-17T00:00:57+02:00] view original

  I think one of the strong points of Mummy is that you simply don't have to care about this one.

---

• Cnerd (orginal) [2025-08-17T00:04:20+02:00] view original

  So mummy justs spawns new thread for each request, thereby automatically making it non blocking to other requests?

---

• Cnerd (orginal) [2025-08-17T00:05:02+02:00] view original

  Would that not generate a lot of overhead when handling a large amount of connection

---

• guzba (orginal) [2025-08-17T00:12:33+02:00] view original

  Mummy does not spawn threads for requests, a fixed pool of them are initialized at start-up and requests are handled by them. You can determine the number of worker threads when you set up the server https://github.com/guzba/mummy/blob/master/tests/wrk_mummy.nim#L15

---

• Cnerd (orginal) [2025-08-17T00:18:58+02:00] view original

  Neat. But how does it handle multiple long term websocket connections alongside http connections if I set let's say max 8 threads for the threadpool?

---

• guzba (orginal) [2025-08-17T04:49:32+02:00] view original

  It will handle that just fine, even to millions of websocket connections if you have enough memory.

  Each incoming websocket message is treated as it's own thread task (similar to each HTTP request).

  For websockets, each connection has a message queue so you'll only ever be processing one event from a websocket connection at a time.

---

• Cnerd (orginal) [2025-08-17T08:26:28+02:00] view original

  Very nice design. Thanks for answering my questions

---