IRC.

2 files changed, 27 insertions, 1 deletions

diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn
index 95b9e545..39478f20 100644
--- a/open_issues/placement_of_virtual_memory_regions.mdwn
+++ b/open_issues/placement_of_virtual_memory_regions.mdwn
@@ -10,7 +10,7 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_gnumach]]
 
-IRC, freenode, #hurd, 2011-07-13
+# IRC, freenode, #hurd, 2011-07-13
 
     <braunr> does anyone know if posix (or mach) has requirements or a policy
       about the placement of allocations of virtual space ?
@@ -87,3 +87,17 @@ IRC, freenode, #hurd, 2011-07-13
     <braunr> jkoenig: i really want to miss as little as possible on the vm
       part, so having detailed information about what actually happens on
       running hurd systems is something i need
+
+
+# IRC, freenode, #hurd, 2011-07-24
+
+    <braunr> oh btw, i noticed there are many mappings below the program text
+    <braunr> most notably, the stack
+    <braunr> except for special applications like wine, could this break
+      anything ?
+    <braunr> i also wonder how libraries are mapped, because there is nothing
+      to perform top-down allocations
+    <braunr> which means if the region below the program text is exhausted,
+      libraries could be mapped right after the heap
+    <youpi> it shouldn't break anything except things like wine & libgc, yes
+    <braunr> which could make malloc() fail :/
diff --git a/open_issues/rm_fr.mdwn b/open_issues/rm_fr.mdwn
index 89a803ab..aab52d97 100644
--- a/open_issues/rm_fr.mdwn
+++ b/open_issues/rm_fr.mdwn
@@ -25,3 +25,15 @@ really waits for all I/Os, which basically means strictly serializing
 file removals: remove one file, wait for the disk to have done it
 (~10ms), remove the next one, etc.  I guess this is for safety reasons
 against crashes, but isn't the sync option there for such kind of
+
+
+# IRC, freenode, #hurd, 2011-07-23
+
+    <antrik> youpi: hm... async deletion does have one downside: I just removed
+      something to make space, and retried the other command immediately
+      afterwards, and it still said "no space left on device"... a few seconds
+      later (after the next regular sync I suppose?) it worked
+    <youpi> well, that's sorta expected, yes
+    <youpi> we get the same on Linux
+    <youpi> Mmm, on second thought, I'm not sure how that can happen
+    <youpi> the asynchronous thing is for disk writes, not cache writes