similar to: Efficient Green Thread Context-Switching

Sorry, I certainly didn't mean to be dishonest. I was just repeating one of the comparisons given by the research paper. Regardless, even setjmp() uses a structure of 148 bytes in size (on my machine). The main point is that with compiler support, many context switches can be easily reduced to just a few instructions and only 8 byte of memory, and even in the worst case they will outperform

Kenneth Uildriks <kennethuil at gmail.com> wrote: > As I see it, the context switching mechanism itself needs to know > where to point the stack register when switching.  The C routines take > an initial stack pointer when creating the context, and keep track of > it from there.  If we don't actually need to interoperate with > contexts created from the C routines, we have

Right now the functionality is available, sometimes, from the C standard library. But embedded environments (often running a limited standard library) and server environments would benefit heavily from a standard way to specify context switches within a single thread in the style of makecontext/swapcontext/setcontext, and built-in support for these operations would also open the way for

On Sun, Apr 11, 2010 at 4:09 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > Kenneth Uildriks <kennethuil at gmail.com> wrote: >> As I see it, the context switching mechanism itself needs to know >> where to point the stack register when switching.  The C routines take >> an initial stack pointer when creating the context, and keep track of >> it from

I took the liberty of forwarding this to the Stackless Python list, since they switch stacks, and I got a response at http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4467. The upshot is that they really need the ability to allocate only a tiny amount of space for each thread and grow that as the thread actually uses more stack. The way they accomplish that now is by copying the

The first time you said “setjmp/longjmp intrinsics” I thought it was a typo, and that you were talking about the C standard library functions. If you’re actually talking about LLVM intrinsics, are they documented? I don’t see any intrinsics with those names in the language reference (https://llvm.org/docs/LangRef.html <https://llvm.org/docs/LangRef.html>). > On Mar 27, 2020, at 3:30 PM,

Hello- Shouldn't this catch swapcontext as well? Alistair On 26 May 2010, at 22:14, Dale Johannesen wrote: > > On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: > >> vfork and getcontext have wildly platform-dependent semantics. >> Handling >> them conservatively is reasonable, even if some platforms don't need >> it. >> >> Dan >

On Sun, Apr 11, 2010 at 2:41 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Sun, Apr 11, 2010 at 4:09 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> Kenneth Uildriks <kennethuil at gmail.com> wrote: >>> As I see it, the context switching mechanism itself needs to know >>> where to point the stack register when switching.  The C

On Sun, Apr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > I'll forward your next draft back to the stackless folks, unless you > want to pick up the thread with them. Their reply: http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4475 Instead of @llvm.getcontextstacktop(%context), they want @llvm.getcurrentstacktop() so that they can copy

On Fri, Apr 16, 2010 at 9:30 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Sun, Apr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> I'll forward your next draft back to the stackless folks, unless you >> want to pick up the thread with them. > > Their reply: http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4475

I didn't see swapcontext in the list in gcc's special_function_p function... -bw On May 26, 2010, at 2:20 PM, Alistair Lynn wrote: > Hello- > > Shouldn't this catch swapcontext as well? > > Alistair > > On 26 May 2010, at 22:14, Dale Johannesen wrote: > >> >> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >> >>> vfork and

Are there any plans to add stack switching to LLVM? I've seen a few proposals for it floating around (some even implemented): http://ulir.ul.ie/handle/10344/2927 (implemented in: https://github.com/stedolan/llvm) https://code.google.com/p/llvm-stack-switch/ But I couldn't find any discussion of whether there was a plan to integrate one of these. Any plans to add this feature? Thanks,

Hi I'm running safe_asterisk, but get core-files in /tmp - how do I debug them ? I know gdb asterisk core.12370 and bt full But it didn't show anything usefull for me. Can anyone help me ? (Running asterisk 1.0.2 with ast_data /Hans-Henrik ----------------- Last from bt full: priority=200, callerid=0x81b8e90 "Dial", action=1134845864) at pbx.c:1384 e =

Like some others on the list spandsp is segfaulting asterisk when recieving a fax. I'm on debian testing/unstable with freshly checked out asterisk CVS and sandsp. My libtiff version is 3.6.1. Here is the GDB output --- snip ----- Changed from phase 5 to 4 Start rx document - compression 2 Start rx page >>> CFR: 84 HDLC underflow in state 5 Post trainability Changed from phase

On Mon, Apr 12, 2010 at 6:15 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > I created a wiki at http://code.google.com/p/llvm-stack-switch/ > > Right now I just copied and formatted the document as-is... I'll go > back over it with your comments in mind soon.  One more question, > which you can answer here or there: > >> Point 4 is a bit confusing.

I'm very interested in seeing support for stack/context switching in LLVM, if only for prototyping language ideas. I'm particularly interested in mechanisms that would make it possible to implement full asymmetric coroutines as described in "Revisiting Coroutines" (Moura & Ierusalimschy, Feb 2009 TOPLAS). From skimming the thread and looking at the llvm-stack-switch wiki, it

On the other hand, stack manipulation really ought to be handled by the target, since only the target knows the details of how the stack is laid out to begin with. Also, if we have stack manipulation calls in the IR, optimization quickly becomes very difficult. Unless we just allow optimizers to ignore the stack manipulations and assume they're doing the "right" thing. On the

Hello guys, native drivers are mad for my laptop: Downgrade to native centos kernel vmlinuz-3.10.0-327.18.2.el7.x86_64. fglrx glxgears around ~800 in 5 seconds my test with amdgpu kernel 4.6 (intel vs amdgpu): [andy at localhost ~]$ cat /proc/version Linux version 4.6.0-1.el7.centos.x86_64 (andy at localhost.localdomain) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) ) #1 SMP Thu May 19

Having read through Stackless Python's web pages a bit: 1. They're doing pretty much what I'd like to do, except that I don't want to be tied to a particular language and I'd like to be able to use the stack. (Also, stack use is inescapable with LLVM, as far as I can tell). 2. We should be able to support "hard switching" in Stackless Python by adding a

Hi, I'm running the latest CVS HEAD version of asterisk, and I'm experiencing hangups during voice conversation. This happens quite regularely and often. The problem is in dsp.c, line 1235, where it says accum /= len; But `len', at this point, is 0, resulting in a SIGFPE. The routine ast_frame *i4l_read() in channels/chan_modem_i4l.c:411 is setting p->fr.datalen to