From 6c7d45e4631784d0e077e806521a736da6b0266e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwinge@gnu.org>
Date: Sun, 7 Apr 2013 18:18:44 +0200
Subject: IRC.

---
 open_issues/multithreading.mdwn | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

(limited to 'open_issues/multithreading.mdwn')

diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
index d7804864..03614fae 100644
--- a/open_issues/multithreading.mdwn
+++ b/open_issues/multithreading.mdwn
@@ -354,6 +354,33 @@ Tom Van Cutsem, 2009.
 [[hurd/libpager]].
 
 
+### IRC, freenode, #hurd, 2013-03-29
+
+    <braunr> some day i'd like to add a system call that threads can use to
+      terminate themselves, passing their stack as a parameter for deallocation
+    <braunr> then, we should review the timeouts used with libports management
+    <braunr> having servers go away when unneeded is a valuable and visible
+      feature of modularity
+
+
+### IRC, freenode, #hurd, 2013-04-03
+
+    <braunr> youpi: i also run without the libports_stability patch
+    <braunr> and i'd like it to be removed unless you still have a good reason
+      to keep it around
+    <youpi> well, the reason I know is mentioned in the patch
+    <youpi> i.e. the box becomes unresponsive when all these threads wake up at
+      the same time
+    <youpi> maybe we could just introduce some randomness in the sleep time
+    <braunr> youpi: i didn't experience the problem
+    <youpi> well, I did :)
+    <braunr> or if i did, it was very short
+    <youpi> for the libports stability, I'd really say take a random value
+      between timeout/2 and timeout
+    <youpi> and that should just nicely fix the issue
+    <braunr> ok
+
+
 ## Alternative approaches:
 
   * <http://www.concurrencykit.org/>
-- 
cgit v1.2.3