Date: Tue, 16 Sep 1997 03:58:33 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: karpen@ocean.campus.luth.se (Mikael Karpberg) Cc: dyson@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: What is wrong with this snipet? Message-ID: <199709160858.DAA00240@dyson.iquest.net> In-Reply-To: <199709160835.KAA04626@ocean.campus.luth.se> from Mikael Karpberg at "Sep 16, 97 10:35:49 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Mikael Karpberg said: > > This is kinda interesting. You can't move forward or backwards in the > stack, which means you can't call functions or return from functions. > You can possibly calculate two values at the same time, withing the same > function, without calling another function. This doesn't seem overly > useful, however. > > What am I missing? Could you make a short example of a use for this? > 1) Have a new stack ready 2) Push the address of the start of the thread onto the new stack. 3) call rfork with RFMEM and other flags. 4a) In the child, immediately set the stack pointer to the new one that was prepared in the parent. Issue a return instruction. 4b) In the parent, continue on. The key to this working is to avoid dependence on the stack in the child until the new stack pointer is loaded. The only problem that I can see, is the possibility of a signal being issued while the child is temporarily using (and avoiding actual use of) the parent's stack. That problem is evil, but there are a couple of workarounds for it (specifically, there is another rfork bit that says that it is a thread creation.) We can hold signals until the child thread is ready to accept them. I suspect that the thread creation bit will be used to hold signal delivery in the child, and the child will have to explicitly enable delivery. This will generally be transparent to the user (unless the user will be writing their own thread support code.) -- John dyson@freebsd.org jdyson@nc.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709160858.DAA00240>