Hello, I use boost_context for a toy project of coroutine scheduler

I need to go, but it seems you're right: <a href="https://ibb.co/bYbpic" rel="nofollow

Some troubles trying to contruct an execution_context (v2) while sitting on the stack of another one about context HOT 6 CLOSED

boostorg commented on August 18, 2024

Some troubles trying to contruct an execution_context (v2) while sitting on the stack of another one

from context.

Comments (6)

olk commented on August 18, 2024

maybe the stack is too small

from context.

matovitch commented on August 18, 2024

But the 2 stacks are allocated on the heap with the stack allocator isn't it ?

FYI, here are the value of the registers (it's the popping of RBP valgrind complains about):

(gdb) i r
rax            0x7fffffffdb08	140737488345864
rbx            0x0	0
rcx            0x0	0
rdx            0x62ac60	6466656
rsi            0x7fffffffd8e8	140737488345320
rdi            0x7fffffffdb08	140737488345864
rbp            0x7fffffffdb60	0x7fffffffdb60
rsp            0x7fffffffda70	0x7fffffffda70
r8             0xffffffffffffffff	-1
r9             0x0	0
r10            0x22	34
r11            0x246	582
r12            0x4016c0	4200128
r13            0x7fffffffdc40	140737488346176
r14            0x0	0
r15            0x0	0
rip            0x4017e4	0x4017e4 <main()+42>
eflags         0x202	[ IF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0
(gdb) c
Continuing.

Breakpoint 2, <lambda()>::operator()(void) const (__closure=0x64ae20) at ../examples/nested.cpp:23
23	            auto&& leafTask = scheduler.makeTask<void>();
(gdb) i r
rax            0x64ae20	6598176
rbx            0x40c40c	4244492
rcx            0x0	0
rdx            0x64ae20	6598176
rsi            0x64aa97	6597271
rdi            0x64ae20	6598176
rbp            0x64a9a0	0x64a9a0
rsp            0x64a980	0x64a980
r8             0x40c863	4245603
r9             0x0	0
r10            0xa42	2626
r11            0x7ffff7adeaf0	140737348758256
r12            0x7ffff7f15018	140737353175064
r13            0x0	0
r14            0x0	0
r15            0x0	0
rip            0x4017a4	0x4017a4 <<lambda()>::operator()(void) const+12>
eflags         0x202	[ IF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0

edit: The first display is the first (non-nested) makeTask.

from context.

matovitch commented on August 18, 2024

Mea culpa. Nothing to do with boost_context, I had forgotten a return there, so it failed on the allocation of the second buffer by my home-made allocator, I should have looked at the back-trace better. Sorry for disturbing you. :(

Thanks and have a nice day !

from context.

matovitch commented on August 18, 2024

Now ~1s for more than half a million tasks (1<<19) in a binary-tree-like DAG on my old 4300FX (on a single core of course). Not too bad ! I will try to profile to see what took most of the time. Pretty sure it's the context switch but cannot be too sure. Sorry again for bothering you and thanks for your work ! :)

from context.

olk commented on August 18, 2024

I guess that the memory allcoation/deallocation cosnumes most of the time.
(at my E5-2620 v4 a pure context switch costs 9 cpu cycles)

from context.

matovitch commented on August 18, 2024

I need to go, but it seems you're right: https://ibb.co/bYbpic.

edit: I am even wondering if there isn't something wrong. There are a lot of allocations.

from context.

Some troubles trying to contruct an execution_context (v2) while sitting on the stack of another one about context HOT 6 CLOSED

Comments (6)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent