On Sun, Jan 26, 2014 at 2:02 PM, Gábor Lehel <[email protected]> wrote:
> > > > On Sat, Jan 25, 2014 at 9:26 PM, Vadim <[email protected]> wrote: > >> Hi Bill, >> If I understand this right, what you are proposing is the approach of >> Python's greenlets library, which I already tried to pitch >> here<http://mail.mozilla.org/pipermail/rust-dev/2013-November/006544.html>. >> >> >> I think that the biggest problem with this approach, in its' raw form, is >> that greenlets are bound to a specific OS thread, which would cause all >> sorts of headache. For example: >> - It would be difficult to balance greenlet tasks between several OS >> threads, >> - If async I/O requests for two greenlets, bound to the same OS thread, >> were to complete simultaneously, you would not be able to resume them in >> parallel, >> - If a thread were to become blocked for a significant amount of time, >> all the greenlets bound to it become un-resumable, >> and so on... >> >> Greelets would be much more palatable if their stacks were >> position-independent. This might be possible to achieve with a suitable >> LLVM >> transform<http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069662.html>, >> though I am not yet sure how portable this would be. >> > > Totally not an expert in this area, but I'm wondering two things: > > - Once you hoist all variables whose address is taken out into this > secondary stack frame, if you have a pointer on the stack to an object on > the stack who *also*, in turn, has its address taken, then I believe you > would end up with a pointer in the secondary stack frame to an object in > the secondary stack frame, i.e. the secondary stack frame itself would not > be position independent. Does the secondary stack frame always stay in > place, so we don't really care about this? > (Thinking about this further, this was a silly question, because the primary stack frame itself would have pointers into the secondary one, so _obviously_ the latter cannot move.)
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
