From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Date: Sat, 5 Sep 2015 16:03:55 +0200 Message-ID: From: Giacomo Tesio To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=f46d04428802ac93b8051f007c74 Subject: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 68b6a8d8-ead9-11e9-9d60-3106f5b1d025 --f46d04428802ac93b8051f007c74 Content-Type: text/plain; charset=UTF-8 2011-05-20 3:30 GMT+02:00 erik quanstrom : > one note is that while i'm aware of privalloc(2), i didn't use it. the > implementation doesn't appear correct for shared-memory procs. > i think there are two issues > - locking is unnecessary. the only preemptable unit of execution is > a process and each process is guarenteed to have its own instance > of _privates and _nprivates. > - for shared-memory procs, we will run out of privates because > the static privinit will be falsely shared. privinit should be replaced > by using a private entry. > In a set of processes that share memory, I need a single per-process location to store the address of structure (which is in turn allocated in the global memory space). Privalloc(2) seemed what I need, but seem that I can't use it properly. In the parent process I do: 1) initialialize a global variable p = (MyStruct **)privalloc(); 2) allocate a MyStruct for every process I'm going to spawn 3) spawn processes with rfork(RFMEM|RFPROC) The spawn() function that call rfork takes a MyStruct* as argument and assign it to *p in the new process. For extra safety I added an assert(*p == nil) just after rfork, and after a few (apparently?) successful spawns, the assert fails. What I need is a sort of thread-local storage for the MyStruct*, so that each child process can find it's own dedicated MyStruct. I know that could get this with an hashtable based on the pid, but I'd prefer to avoid the book keeping if possible. Giacomo --f46d04428802ac93b8051f007c74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2011-05-20 3:30 GMT+02:00 erik quanstrom <quanstro@qu= anstro.net>:
one note is that while i'm awar= e of privalloc(2), i didn't use it.=C2=A0 the
implementation doesn't appear correct for shared-memory procs.
i think there are two issues
- locking is unnecessary.=C2=A0 the only preemptable unit of execution is a process and each process is guarenteed to have its own instance
of _privates and _nprivates.
- for shared-memory procs, we will run out of privates because
the static privinit will be falsely shared.=C2=A0 privinit should be replac= ed
by using a private entry.

In a set of p= rocesses that share memory, I need a single per-process location to store t= he address of structure (which is in turn allocated in the global memory sp= ace).

Privalloc(2) seemed what I need, but seem that I ca= n't use it properly.

In the parent process I do:
<= br>
1) initialialize a global variable p =3D (MyStruct **)privall= oc();
2) allocate a MyStruct for every process I'm going = to spawn
3) spawn processes with rfork(RFMEM|RFPROC)

=
The spawn() function that call rfork takes a MyStruct* as argume= nt and assign it to *p in the new process.
For extra safety I added an a= ssert(*p =3D=3D nil) just after rfork, and after a few (apparently?) succes= sful spawns, the assert fails.

What I need is a sort of t= hread-local storage for the MyStruct*, so that each child process can find = it's own dedicated MyStruct.
I know that could get this w= ith an hashtable based on the pid, but I'd prefer to avoid the book kee= ping if possible.


Giacomo
--f46d04428802ac93b8051f007c74-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Sat, 5 Sep 2015 16:11:44 +0200 Message-ID: From: Giacomo Tesio To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=f46d0442880298d0aa051f0098d5 Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 68c08e98-ead9-11e9-9d60-3106f5b1d025 --f46d0442880298d0aa051f0098d5 Content-Type: text/plain; charset=UTF-8 ... and given getpid(2) implementation, a pid based table could be quite expensive, since MyStruct is accessed very very often. 2015-09-05 16:03 GMT+02:00 Giacomo Tesio : > 2011-05-20 3:30 GMT+02:00 erik quanstrom : > >> one note is that while i'm aware of privalloc(2), i didn't use it. the >> implementation doesn't appear correct for shared-memory procs. >> i think there are two issues >> - locking is unnecessary. the only preemptable unit of execution is >> a process and each process is guarenteed to have its own instance >> of _privates and _nprivates. >> - for shared-memory procs, we will run out of privates because >> the static privinit will be falsely shared. privinit should be replaced >> by using a private entry. >> > > In a set of processes that share memory, I need a single per-process > location to store the address of structure (which is in turn allocated in > the global memory space). > > Privalloc(2) seemed what I need, but seem that I can't use it properly. > > In the parent process I do: > > 1) initialialize a global variable p = (MyStruct **)privalloc(); > 2) allocate a MyStruct for every process I'm going to spawn > 3) spawn processes with rfork(RFMEM|RFPROC) > > The spawn() function that call rfork takes a MyStruct* as argument and > assign it to *p in the new process. > For extra safety I added an assert(*p == nil) just after rfork, and after > a few (apparently?) successful spawns, the assert fails. > > What I need is a sort of thread-local storage for the MyStruct*, so that > each child process can find it's own dedicated MyStruct. > I know that could get this with an hashtable based on the pid, but I'd > prefer to avoid the book keeping if possible. > > > Giacomo > --f46d0442880298d0aa051f0098d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
... and given getpid(2) implementation, a pid based table = could be quite expensive, since MyStruct is accessed very very often.

2015-09-05 16= :03 GMT+02:00 Giacomo Tesio <giacomo@tesio.it>:
2011-05-20 3:30 GMT+02:00 erik quanst= rom <quanstro@quanstro.net>:
one note is = that while i'm aware of privalloc(2), i didn't use it.=C2=A0 the implementation doesn't appear correct for shared-memory procs.
i think there are two issues
- locking is unnecessary.=C2=A0 the only preemptable unit of execution is a process and each process is guarenteed to have its own instance
of _privates and _nprivates.
- for shared-memory procs, we will run out of privates because
the static privinit will be falsely shared.=C2=A0 privinit should be replac= ed
by using a private entry.

In a set of p= rocesses that share memory, I need a single per-process location to store t= he address of structure (which is in turn allocated in the global memory sp= ace).

Privalloc(2) seemed what I need, but seem that I ca= n't use it properly.

In the parent process I do:
<= br>
1) initialialize a global variable p =3D (MyStruct **)privall= oc();
2) allocate a MyStruct for every process I'm going = to spawn
3) spawn processes with rfork(RFMEM|RFPROC)

=
The spawn() function that call rfork takes a MyStruct* as argume= nt and assign it to *p in the new process.
For extra safety I added an a= ssert(*p =3D=3D nil) just after rfork, and after a few (apparently?) succes= sful spawns, the assert fails.

What I need is a sort of t= hread-local storage for the MyStruct*, so that each child process can find = it's own dedicated MyStruct.
I know that could get this w= ith an hashtable based on the pid, but I'd prefer to avoid the book kee= ping if possible.

Gi= acomo

--f46d0442880298d0aa051f0098d5-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 5 Sep 2015 08:27:30 -0700 To: 9fans@9fans.net Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 68c98336-ead9-11e9-9d60-3106f5b1d025 On Sat Sep 5 07:06:44 PDT 2015, giacomo@tesio.it wrote: > 2011-05-20 3:30 GMT+02:00 erik quanstrom : uh, wow. i hope this wasn't my mailer dragging the past up. > > one note is that while i'm aware of privalloc(2), i didn't use it. the > > implementation doesn't appear correct for shared-memory procs. > > i think there are two issues > > - locking is unnecessary. the only preemptable unit of execution is > > a process and each process is guarenteed to have its own instance > > of _privates and _nprivates. > > - for shared-memory procs, we will run out of privates because > > the static privinit will be falsely shared. privinit should be replaced > > by using a private entry. > > > > In a set of processes that share memory, I need a single per-process > location to store the address of structure (which is in turn allocated in > the global memory space). > > Privalloc(2) seemed what I need, but seem that I can't use it properly. > > In the parent process I do: > > 1) initialialize a global variable p = (MyStruct **)privalloc(); > 2) allocate a MyStruct for every process I'm going to spawn > 3) spawn processes with rfork(RFMEM|RFPROC) > > The spawn() function that call rfork takes a MyStruct* as argument and > assign it to *p in the new process. > For extra safety I added an assert(*p == nil) just after rfork, and after a > few (apparently?) successful spawns, the assert fails. hmm. in /sys/src/libc/amd64/arv0.s _privates and _nprivates are in the bss. GLOBL _privates(SB), $8 GLOBL _nprivates(SB), $4 so they can be set in the parent process. in /sys/src/libc/amd64/main9.s #define NPRIVATES 16 TEXT _main(SB), 1, $(2*8+NPRIVATES*8) MOVQ AX, _tos(SB) LEAQ 16(SP), AX MOVQ AX, _privates(SB) MOVL $NPRIVATES, _nprivates(SB) we see that the privates and nprivates are on the stack just below _tos. the only ways i can see your pointer not being nil is (a) kernel bug -- the stack is not cleared (b) the the parent has written to the privalloc'd element before forking, and the stack was copied faithfully. i think you can tell which case you have by assert(*p == nil) in the parent. i'm sure there could be other bugs as well. as to getpid() being "slow", you can always use _tos->pid - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 5 Sep 2015 09:41:02 -0700 To: 9fans@9fans.net Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 68fa57fe-ead9-11e9-9d60-3106f5b1d025 by the way, the following program runs without asserting for me with or without the waits. - erik --- #include #include void task(void **p) { assert(*p == nil); *p = (void*)(uintptr)getpid(); } void spawn(void (*t)(void**), void **p) { int pid; switch(pid = rfork(RFMEM|RFPROC)){ case -1: sysfatal("spawn: rfork: %r"); case 0: t(p); exits(""); default: USED(pid); return; } } void main(void) { int i, k; void **p; Waitmsg *w; p = privalloc(); k = 0; for(i = 0; i < 1024; i++){ spawn(task, p); for(k++; k > 16; k--){ if((w = wait()) == nil) break; free(w); } } exits(""); } From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Sat, 5 Sep 2015 20:42:41 +0200 Message-ID: From: Giacomo Tesio To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1130d3969b48a8051f0461d1 Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 69002c9c-ead9-11e9-9d60-3106f5b1d025 --001a1130d3969b48a8051f0461d1 Content-Type: text/plain; charset=UTF-8 Nice example thanks. May be my problem is that p is global in my case? Giacomo Il 05/Set/2015 18:50, "erik quanstrom" ha scritto: > by the way, the following program runs without asserting for me > with or without the waits. > > - erik > > --- > > #include > #include > > void > task(void **p) > { > assert(*p == nil); > *p = (void*)(uintptr)getpid(); > } > > void > spawn(void (*t)(void**), void **p) > { > int pid; > > switch(pid = rfork(RFMEM|RFPROC)){ > case -1: > sysfatal("spawn: rfork: %r"); > case 0: > t(p); > exits(""); > default: > USED(pid); > return; > } > } > > void > main(void) > { > int i, k; > void **p; > Waitmsg *w; > > p = privalloc(); > k = 0; > for(i = 0; i < 1024; i++){ > spawn(task, p); > for(k++; k > 16; k--){ > if((w = wait()) == nil) > break; > free(w); > } > } > exits(""); > } > > --001a1130d3969b48a8051f0461d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPk5pY2UgZXhhbXBsZSB0aGFua3MuPC9wPg0KPHAgZGlyPSJsdHIiPk1heSBi ZSBteSBwcm9ibGVtIGlzIHRoYXQgcCBpcyBnbG9iYWwgaW4gbXkgY2FzZT88YnI+PC9wPg0KPHAg ZGlyPSJsdHIiPkdpYWNvbW88L3A+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+SWwgMDUvU2V0 LzIwMTUgMTg6NTAsICZxdW90O2VyaWsgcXVhbnN0cm9tJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86cXVhbnN0cm9AcXVhbnN0cm8ubmV0Ij5xdWFuc3Ryb0BxdWFuc3Ryby5uZXQ8L2E+Jmd0OyBo YSBzY3JpdHRvOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+YnkgdGhlIHdheSwgdGhlIGZvbGxvd2luZyBwcm9ncmFtIHJ1 bnMgd2l0aG91dCBhc3NlcnRpbmcgZm9yIG1lPGJyPg0Kd2l0aCBvciB3aXRob3V0IHRoZSB3YWl0 cy48YnI+DQo8YnI+DQotIGVyaWs8YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQojaW5jbHVkZSAm bHQ7dS5oJmd0Ozxicj4NCiNpbmNsdWRlICZsdDtsaWJjLmgmZ3Q7PGJyPg0KPGJyPg0Kdm9pZDxi cj4NCnRhc2sodm9pZCAqKnApPGJyPg0Kezxicj4NCsKgIMKgIMKgIMKgIGFzc2VydCgqcCA9PSBu aWwpOzxicj4NCsKgIMKgIMKgIMKgICpwID0gKHZvaWQqKSh1aW50cHRyKWdldHBpZCgpOzxicj4N Cn08YnI+DQo8YnI+DQp2b2lkPGJyPg0Kc3Bhd24odm9pZCAoKnQpKHZvaWQqKiksIHZvaWQgKipw KTxicj4NCns8YnI+DQrCoCDCoCDCoCDCoCBpbnQgcGlkOzxicj4NCjxicj4NCsKgIMKgIMKgIMKg IHN3aXRjaChwaWQgPSByZm9yayhSRk1FTXxSRlBST0MpKXs8YnI+DQrCoCDCoCDCoCDCoCBjYXNl IC0xOjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHN5c2ZhdGFsKCZxdW90O3NwYXduOiBy Zm9yazogJXImcXVvdDspOzxicj4NCsKgIMKgIMKgIMKgIGNhc2UgMDo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB0KHApOzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4aXRzKCZx dW90OyZxdW90Oyk7PGJyPg0KwqAgwqAgwqAgwqAgZGVmYXVsdDo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBVU0VEKHBpZCk7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmV0dXJu Ozxicj4NCsKgIMKgIMKgIMKgIH08YnI+DQp9PGJyPg0KPGJyPg0Kdm9pZDxicj4NCm1haW4odm9p ZCk8YnI+DQp7PGJyPg0KwqAgwqAgwqAgwqAgaW50IGksIGs7PGJyPg0KwqAgwqAgwqAgwqAgdm9p ZCAqKnA7PGJyPg0KwqAgwqAgwqAgwqAgV2FpdG1zZyAqdzs8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCBwID0gcHJpdmFsbG9jKCk7PGJyPg0KwqAgwqAgwqAgwqAgayA9IDA7PGJyPg0KwqAgwqAgwqAg wqAgZm9yKGkgPSAwOyBpICZsdDsgMTAyNDsgaSsrKXs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBzcGF3bih0YXNrLCBwKTs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmb3Ioaysr OyBrICZndDsgMTY7IGstLSl7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgaWYoKHcgPSB3YWl0KCkpID09IG5pbCk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBicmVhazs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBmcmVlKHcpOzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIH08YnI+ DQrCoCDCoCDCoCDCoCB9PGJyPg0KwqAgwqAgwqAgwqAgZXhpdHMoJnF1b3Q7JnF1b3Q7KTs8YnI+ DQp9PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPjwvZGl2Pg0K --001a1130d3969b48a8051f0461d1-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 5 Sep 2015 11:47:17 -0700 To: 9fans@9fans.net Message-ID: <8b5a65de5cd93ec6242b885530caf86f@brasstown.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 69058732-ead9-11e9-9d60-3106f5b1d025 > May be my problem is that p is global in my case? global variables are in the bss, and thus shared. p will have the same value in each thread, but *p should point into the stack, and thus the same virtual address will be mapped to different physical pages of memory. however, if *p is assigned to a non-zero value before the process is created, the new page allocated for the new process' stack will have a copy of the old value, and thus not be 0. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6b0caf673af37219d9d9f79a66ad4159@felloff.net> Date: Sat, 5 Sep 2015 20:56:24 +0200 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 690b2142-ead9-11e9-9d60-3106f5b1d025 it doesnt matter. p is a pointer to a pointer. the whole idea of privalloc() is to give you a memory locaiton that when *dereferenced* can yield different *values* under different processes, tho the *address* is the same, so it can be passed arround. -- cinap From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Sat, 5 Sep 2015 23:45:53 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113dea225f197b051f07c772 Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 6910ddd0-ead9-11e9-9d60-3106f5b1d025 --001a113dea225f197b051f07c772 Content-Type: text/plain; charset=UTF-8 On 5 September 2015 at 15:03, Giacomo Tesio wrote: > For extra safety I added an assert(*p == nil) just after rfork, and after > a few (apparently?) successful spawns, the assert fails. The stack is a logical copy of the parent process's stack at rfork, even with RFMEM, since the stack's not shared, so if you've previously assigned it in the parent, its child will see the non-nil value after the fork. It doesn't get a completely fresh stack. --001a113dea225f197b051f07c772 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 5 September 2015 at 15:03, Giacomo Tesio <giacomo@tesio.it> wrote:
For extra safety I added an as= sert(*p =3D=3D nil) just after rfork, and after a few (apparently?) success= ful spawns, the assert fails.

The stack is a logical = copy of the parent process's stack at rfork, even with RFMEM, since the= stack's not shared,
so if you've p= reviously assigned it in the parent, its child will see the non-nil value a= fter the fork. It doesn't get a completely fresh stack.
--001a113dea225f197b051f07c772-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <8b5a65de5cd93ec6242b885530caf86f@brasstown.quanstro.net> References: <8b5a65de5cd93ec6242b885530caf86f@brasstown.quanstro.net> Date: Sun, 6 Sep 2015 01:03:38 +0200 Message-ID: From: Giacomo Tesio To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7bd6b9a4df6f08051f080646 Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 691b8492-ead9-11e9-9d60-3106f5b1d025 --047d7bd6b9a4df6f08051f080646 Content-Type: text/plain; charset=UTF-8 2015-09-05 20:47 GMT+02:00 erik quanstrom : > > May be my problem is that p is global in my case? > > global variables are in the bss, and thus shared. p will have > the same value in each thread, but *p should point into the > stack, and thus the same virtual address will be mapped to > different physical pages of memory. > > however, if *p is assigned to a non-zero value before the process > is created, the new page allocated for the new process' stack will > have a copy of the old value, and thus not be 0. > > - erik > > That's exactly what happened. I misread privalloc(2), and assumed that privalloc()ed addresses were somehow reset on rfork. This is probably something to explicitly state the man page. Thanks you all! Giacomo --047d7bd6b9a4df6f08051f080646 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015-09-05 20:47 GMT+02:00 erik quanstrom <quanstro@q= uanstro.net>:
> May be my problem is that p is global in my case?

global variables are in the bss, and thus shared. p will have
the same value in each thread, but *p should point into the
stack, and thus the same virtual address will be mapped to
different physical pages of memory.

however, if *p is assigned to a non-zero value before the process
is created, the new page allocated for the new process' stack will
have a copy of the old value, and thus not be 0.

- erik


That's exactly what happened.
=
I misread privalloc(2), and assumed that p= rivalloc()ed addresses were somehow reset on rfork.
This is probably something to explicitly state the man page.<= br>

Thanks you all!


Giacomo
--047d7bd6b9a4df6f08051f080646-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <82a662b665bce9245bfda986a0604ddb@felloff.net> Date: Sun, 6 Sep 2015 01:38:15 +0200 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 69175a34-ead9-11e9-9d60-3106f5b1d025 hey charles! is privfree() broken? it appears it chains the slots together, but only the calling process will get a correct chain. the chain head (privs) is shared (in bss) and seen by all process so the others will get corrupted chains (chain link is private) no? i wonder what the intended use for privfree() was. theres no code using it. -- cinap From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 6 Sep 2015 06:14:48 -0700 To: 9fans@9fans.net Message-ID: <958267eb934f1630a72ca99ac828b3b2@brasstown.quanstro.net> In-Reply-To: <82a662b665bce9245bfda986a0604ddb@felloff.net> References: <82a662b665bce9245bfda986a0604ddb@felloff.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 691f97b2-ead9-11e9-9d60-3106f5b1d025 On Sat Sep 5 23:33:50 PDT 2015, cinap_lenrek@felloff.net wrote: > hey charles! > > is privfree() broken? it appears it chains the slots together, > but only the calling process will get a correct chain. the chain > head (privs) is shared (in bss) and seen by all process so the > others will get corrupted chains (chain link is private) no? > > i wonder what the intended use for privfree() was. theres no > code using it. i think the logic in tprivalloc is what was intended. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <82a662b665bce9245bfda986a0604ddb@felloff.net> References: <82a662b665bce9245bfda986a0604ddb@felloff.net> Date: Sun, 6 Sep 2015 15:12:19 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e0118487485ca35051f14b8c9 Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 692b5f52-ead9-11e9-9d60-3106f5b1d025 --089e0118487485ca35051f14b8c9 Content-Type: text/plain; charset=UTF-8 On 6 September 2015 at 00:38, wrote: > is privfree() broken? it appears it chains the slots together, > but only the calling process will get a correct chain. > The only way it works is to have a main process allocate and free slots for use by all participants, which is a workable scheme in many cases, and indeed preferable to a strictly-local allocation for certain types of data. For instance, to tag a process with (say) an application-defined Proc structure, that structure must be at the same slot in every process to allow it to be found. With that scheme, there isn't any need for the lock, because only one process can call it. If the cells were instead allocated using a strictly local free list or bitmap, which would be possible, there still wouldn't be any need for the lock, so the original thinking is still obscure. i think the logic in tprivalloc is what was intended. > probably, since a shared bitmap would need a lock and allow any process to allocate a slot, which could then either be broadcast to allow per-process tagging (as above), or allocation of a slot of only local interest. even so, tprivfree is incomplete. --089e0118487485ca35051f14b8c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 6 September 2015 at 00:38, <cinap_lenrek@felloff.net> wrote:
is privfree() broken? it appears it chains the slots together, but only the calling process will get a correct chain.

The only way it works is to have a main process allocate and free s= lots for use by
all participants, which is = a workable scheme in many cases, and indeed preferable
to a strictly-local allocation for certain types of data. For i= nstance, to tag a process
with (say) an app= lication-defined Proc structure, that structure must be at the same slot in=
every process to allow it to be found.

With that= scheme, there isn't any need for the lock, because only one
process can call it. If the cells were instead alloca= ted using a strictly local free list or bitmap,
which would be possible, there still wouldn't be any need for = the lock,
so the original thinking is still= obscure.

i think the logic i= n tprivalloc is what was intended.

probably, since a shared bitmap would need a lock and= allow
any process to allocate a slot, which coul= d then either be broadcast
to allow per-process t= agging (as above), or allocation of a slot of only
local interest. even so, tprivfree is incomplete.
--089e0118487485ca35051f14b8c9-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 6 Sep 2015 08:02:22 -0700 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <82a662b665bce9245bfda986a0604ddb@felloff.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 69352712-ead9-11e9-9d60-3106f5b1d025 > probably, since a shared bitmap would need a lock and allow > any process to allocate a slot, which could then either be broadcast > to allow per-process tagging (as above), or allocation of a slot of only > local interest. even so, tprivfree is incomplete. a slot of local interest? doesn't malloc serve that purpose well enough? - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Sun, 6 Sep 2015 20:21:54 +0200 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 693938f2-ead9-11e9-9d60-3106f5b1d025 instead of trying to explain these semantics of privfree() in the manpage, might just get rid of privfree() itself. globally allocate the slots one after another. -- cinap From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <82a662b665bce9245bfda986a0604ddb@felloff.net> Date: Sun, 6 Sep 2015 21:21:34 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113ff9781d8b62051f19e14b Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 693d4d20-ead9-11e9-9d60-3106f5b1d025 --001a113ff9781d8b62051f19e14b Content-Type: text/plain; charset=UTF-8 On 6 September 2015 at 16:02, erik quanstrom wrote: > a slot of local interest? doesn't malloc serve that purpose well enough? It doesn't create a name for a per-process global. --001a113ff9781d8b62051f19e14b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 6 September 2015 at 16:02, erik quanstrom <quanstro@quanstro.net> wrote:
a slot of local inte= rest?=C2=A0 doesn't malloc serve that purpose well enough?
=

It doesn't create a name for a per-process global.
--001a113ff9781d8b62051f19e14b-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Sun, 6 Sep 2015 21:27:40 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1141b24ee828f1051f19f674 Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 69423e0c-ead9-11e9-9d60-3106f5b1d025 --001a1141b24ee828f1051f19f674 Content-Type: text/plain; charset=UTF-8 On 6 September 2015 at 19:21, wrote: > manpage, might just get rid of privfree() itself. globally allocate > the slots one after another. > it's useful to be able to reset some or all of the state in a supervisory process after a failure and restart. the tprivalloc/tprivfree [+bug fix] approach to allocation/deallocation through a global bitmap (but returning a void**) is probably best for the time being, and keeps the same interface and reasonable semantics. --001a1141b24ee828f1051f19f674 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 6 September 2015 at 19:21, <cinap_lenrek@felloff.net> wrote:
manpage, might just get rid of privfree() itsel= f. globally allocate
the slots one after another.

it's usefu= l to be able to reset some or all of the state in a supervisory process aft= er a failure and restart.
the tprivalloc/tp= rivfree [+bug fix] approach to allocation/deallocation through a global bit= map
(but returning a void**) =C2=A0is proba= bly best for the time being, and keeps the same interface and reasonable
semantics.
--001a1141b24ee828f1051f19f674-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 6 Sep 2015 17:30:35 -0700 Message-ID: <9eabf2e2-0586-4c3b-9693-94d10c23deb4@email.android.com> In-Reply-To: From: erik quanstrom To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 69469c90-ead9-11e9-9d60-3106f5b1d025 PHAgZGlyPSJsdHIiPnByaXZhbGxvYyBkb2Vzbid0IGNyZWF0ZSBhIG5hbWUgZWl0aGVyLiZuYnNw OyB1bmxlc3MgYnkgbmFtZSBhbiBlbnRyeSBpbiBhIHRhYmxlIHNoYXJlZCBieSB0aGUgc2V0IG9m IG1lbW9yeSBzaGFyaW5nIHByb2Nlc3NlcyBpcyB3aGF0IGlzIG1lYW50LiZuYnNwOyB0aGlzIGlz IG5vdCBoZWxwZnVsIHRob3VnaCBiZWNhdXNlIEkgd2FzIHNwZWNpZmljYWxseSBhZGRyZXNzaW5n IHRoZSBjYXNlIHdoZXJlIGl0IHdhcyBqdXN0IHByb2Nlc3MgcHJpdmF0ZS48L3A+CjxwIGRpcj0i bHRyIj4tIGVyaWs8YnI+CjwvcD4KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFNlcCA2LCAy MDE1IDE6MjEgUE0sIENoYXJsZXMgRm9yc3l0aCAmbHQ7Y2hhcmxlcy5mb3JzeXRoQGdtYWlsLmNv bSZndDsgd3JvdGU6PGJyIHR5cGU9J2F0dHJpYnV0aW9uJz48YmxvY2txdW90ZSBjbGFzcz0icXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGRpcj0ibHRyIj48ZGl2PjxiciAvPjxkaXYgY2xhc3M9ImVs aWRlZC10ZXh0Ij5PbiA2IFNlcHRlbWJlciAyMDE1IGF0IDE2OjAyLCBlcmlrIHF1YW5zdHJvbSA8 c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpxdWFuc3RybyYjNjQ7cXVhbnN0cm8u bmV0Ij5xdWFuc3RybyYjNjQ7cXVhbnN0cm8ubmV0PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciAv PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+YSBzbG90IG9mIGxvY2FsIGludGVyZXN0P8KgIGRv ZXNuJiMzOTt0IG1hbGxvYyBzZXJ2ZSB0aGF0IHB1cnBvc2Ugd2VsbCBlbm91Z2g/PC9ibG9ja3F1 b3RlPjwvZGl2PjxiciAvPkl0IGRvZXNuJiMzOTt0IGNyZWF0ZSBhIG5hbWUgZm9yIGEgcGVyLXBy b2Nlc3MgZ2xvYmFsLjwvZGl2PjwvZGl2Pg0KDQo8L2Jsb2NrcXVvdGU+PC9kaXY+ From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <9eabf2e2-0586-4c3b-9693-94d10c23deb4@email.android.com> References: <9eabf2e2-0586-4c3b-9693-94d10c23deb4@email.android.com> Date: Mon, 7 Sep 2015 10:38:48 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e011609fc372fec051f250427 Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 694a457a-ead9-11e9-9d60-3106f5b1d025 --089e011609fc372fec051f250427 Content-Type: text/plain; charset=UTF-8 On 7 September 2015 at 01:30, erik quanstrom wrote: > unless by name an entry in a table shared by the set of memory sharing > processes is what is meant the table isn't shared. the address of the table is the same, but the underlying memory is private, and indeed can't be shared (there isn't a system call to map the pages elsewhere in the shared address space). --089e011609fc372fec051f250427 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --089e011609fc372fec051f250427-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <9eabf2e2-0586-4c3b-9693-94d10c23deb4@email.android.com> Date: Mon, 7 Sep 2015 12:59:42 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/mixed; boundary=001a113dea222554d9051f26fc58 Subject: Re: [9fans] Privalloc(2) and rfork(RFPROC|RFMEM) (was: a pair nec bugs) Topicbox-Message-UUID: 69523fd2-ead9-11e9-9d60-3106f5b1d025 --001a113dea222554d9051f26fc58 Content-Type: multipart/alternative; boundary=001a113dea222554d3051f26fc56 --001a113dea222554d3051f26fc56 Content-Type: text/plain; charset=UTF-8 In any case, an implementation along the lines of tprivalloc seems ok, and passes my naive test program. --001a113dea222554d3051f26fc56 Content-Type: text/html; charset=UTF-8
In any case, an implementation along the lines of tprivalloc seems ok,
and passes my naive test program.
--001a113dea222554d3051f26fc56-- --001a113dea222554d9051f26fc58 Content-Type: text/x-csrc; charset=US-ASCII; name="privalloc.c" Content-Disposition: attachment; filename="privalloc.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie9vklfg0 I2luY2x1ZGUgPHUuaD4KI2luY2x1ZGUgPGxpYmMuaD4KCnN0YXRpYyBMb2NrCXByaXZsb2NrOwpz dGF0aWMgaW50CXByaXZpbml0OwpzdGF0aWMgdTMyaW50IHByaXZtYXA7CgpleHRlcm4gdm9pZAkq Kl9wcml2YXRlczsKZXh0ZXJuIGludAlfbnByaXZhdGVzOwoKdm9pZCAqKgpwcml2YWxsb2Modm9p ZCkKewoJdm9pZCAqKnA7CglpbnQgaTsKCglsb2NrKCZwcml2bG9jayk7Cglmb3IoaSA9IDA7IGkg PCAzMiAmJiBpIDwgX25wcml2YXRlczsgaSsrKXsKCQlpZigocHJpdm1hcCAmICgxPDxpKSkgPT0g MCl7CgkJCXByaXZtYXAgfD0gMTw8aTsKCQkJdW5sb2NrKCZwcml2bG9jayk7CgkJCXAgPSAmX3By aXZhdGVzW2ldOwoJCQkqcCA9IG5pbDsKCQkJcmV0dXJuIHA7CgkJfQoJfQoJdW5sb2NrKCZwcml2 bG9jayk7CglyZXR1cm4gbmlsOwp9Cgp2b2lkCnByaXZmcmVlKHZvaWQgKipwKQp7CglpbnQgaTsK CglpZihwICE9IG5pbCl7CgkJaSA9IHAgLSBfcHJpdmF0ZXM7CgkJaWYoaSA8IDAgfHwgaSA+IF9u cHJpdmF0ZXMgfHwgKHByaXZtYXAgJiAoMTw8aSkpID09IDApCgkJCWFib3J0KCk7CgkJbG9jaygm cHJpdmxvY2spOwoJCXByaXZtYXAgJj0gfigxPDxpKTsKCQl1bmxvY2soJnByaXZsb2NrKTsKCX0K fQo= --001a113dea222554d9051f26fc58--