Comments (9)
I feel the big issue with may
is that it does not guard against undefined behavior. I think most use cases don't care that they have to limit their stack size (most co-routines will spawn a single function call!) and wouldn't mind if the coroutine paniced in that case. Undefined behavior, however, is a huge problem.
Is it possible to prevent undefined behavior and instead panic... or even abort?
from may.
cool, thanks for the response!
I think it makes sense for go!
to use the stack probe, but allow users to access a coroutine without probed memory (through an unsafe function) if they really want to squeeze performance.
Thanks!
from may.
from may.
thanks for the link!
currently May
doesn't use guard page for coroutines stacks, this need alloc extra one more page for each coroutine. Now we only has a very unsafe way to probe the stack overflow implemented by checking the footprint of the coroutine stack. So this is why exceed stack could cause undefined behavior.
I check the __rust_probestack
src code and find that this function needs to be called in the user's code, not in the May
library, because it only used for one big single function frame to detect stack overflow, and for libary design we don't have any information about how the stack frames would grow. If users forget call this for a large stack frame (bigger than one page) function it still triggers undefined behavior even we has a stack gurad page here.
from may.
I check the __rust_probestack src code and find that this function needs to be called in the user's code, not in the May library, because it only used for one big single function frame to detect stack overflow, and for libary design we don't have any information about how the stack frames would grow.
I may not be understanding, but if it has to be called "in the user's code" then couldn't the go!
macro call it?
from may.
@vitiral: go!
macro is just a thin wrapper, which doesn't need stack probe at all. only those leaf functions that have very big stack frame would be benefit from __rust_probestack
when they are running with a guard page
on the stack. But may doesn't have guard pages for coroutines now, so call __rust_probestack
is no help.
from may.
yes, it's possible to add a stack guard page for each coroutine. And this would need an extra one page memory allocated. for most cases this is not a big issue which I preferred to add the behavior in future. if stack overflow detected, OS will kill the program with a segment fault(maybe with better output by rust, this is not a UB, I think) just like normal thread stack overflow implemented by rust.
I don't think we can have a panic if stack overflow happened, when panic happened, it will need more stack which would make things worse. If we are using guard page, there is no place to put the panic code, rust run-time takes over the action for stack overflow.
from may.
I think this is a serious issue that prevent people to use may in production.People are not afraid of panic but undefined. 😄
Do you have any plan to fix this issue?
from may.
now the generator lib use guarded stack, may will automatically has the desired behavior.
ref Xudong-Huang/generator-rs#12
from may.
Related Issues (20)
- support cancel feature gate
- macro select! : Polling a channel that already contained data may not trigger recv HOT 3
- Question about coroutine HOT 2
- `go!` macro allows its arguments to do `unsafe` operations. HOT 1
- No `peek` implementation for `net::TcpStream` HOT 2
- How can May be used for shared-nothing architecture? HOT 3
- There is no IO API for File open,write....?
- question: way not generator-rs Stack resizes automatically? HOT 4
- Queue needs bounds on its Send/Sync traits HOT 2
- Examples don't compile HOT 2
- about performace.md The description is unfair HOT 3
- 建议参考ants,整个协程池
- `may_http`耗时不符合预期 HOT 5
- 建议参考libco,hook系统函数,减少改造成本 HOT 1
- 问下如何正确地hook系统函数?
- support linux io_uring HOT 1
- unify thread and coroutine io handling
- split io read and write event HOT 1
- How does it actually work
- linux: file descriptor leak in epoll code HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from may.