Date: Tue, 9 Apr 1996 13:52:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Cc: terry@lambert.org, roell@blah.a.isar.de, hackers@FreeBSD.ORG, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604092052.NAA05915@phaeton.artisoft.com> In-Reply-To: <199604092053.NAA02328@rah.star-gate.com> from "Amancio Hasty Jr." at Apr 9, 96 01:53:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I guess is easier to fire off a process to handle each separate > asynch io stream 8) I would suggest "stack regions" with mapped guard pages for automatic growth. This would require segmenting the kernel address space, since the stacks would really belong to the AST subsystem and be "borrowed" by the process. I believe this is what VMS does. The problem is the amount of work requires to implement the segmentation. VMS has 3 levels of hardware protection, which it uses to implement this. I would prefer to not have to rely on such a limited set of hardware for FreeBSD ports. This means breaking up the mappable data address space into ranges to allow stacks to be page mapped and guarded. Alternately, the compiler could be made to use relative rather than abosolute addressing for stack variables, which would let the stacks be relocated as necessary. This kind of assumes that the default usage would be one page, and that any more would start putting on overhead for page relocation. If stacks were relative, all that I would care about when accessing a stack variable would be the stack base and the relative address from the stack base, instead of the absolute address of where that area of stack is mapped in the dataspace. It's the fixed mapping that screws the ability to run around with multiple stacks (without carving up the data space into "potential stacks with guard pages", I mean). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604092052.NAA05915>