Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

start_reading #1925

Closed
vtjnash opened this issue Jan 8, 2013 · 2 comments
Closed

start_reading #1925

vtjnash opened this issue Jan 8, 2013 · 2 comments
Assignees
@Keno
Labels
domain:io Involving the I/O subsystem: libuv, read, write, etc.
Milestone
0.4.0

Comments

@vtjnash
Copy link
Sponsor Member

vtjnash commented Jan 8, 2013

start_reading / stop_reading are needed on stdin_stream to share it with other processes. when should this be called? how automatic can it be? I suspect it's only needed with respect to spawning, in which case the default state could be start_reading and when spawning call stop_reading on the stream passed for stdin. currently the situation is a bit haphazard.
vtjnash referenced this issue Mar 20, 2013
@Keno
Add option to run event loop once
6b5ad9a
@ghost ghost assigned Keno Jun 20, 2013
@JeffBezanson JeffBezanson removed the kind:speculative Whether the change will be implemented is speculative label Mar 16, 2015
@JeffBezanson JeffBezanson added this to the 0.4 milestone Mar 16, 2015
@JeffBezanson
Copy link
Sponsor Member

start_reading, stop_reading, and start_watching are all undocumented. We really must arrange to remove them from the exports. Nobody wants to have to use these functions.

@JeffBezanson JeffBezanson mentioned this issue Apr 17, 2015
Closed
@jiahao
Copy link
Member

jiahao commented Apr 20, 2015

Closed by #10885 - don't recommend users to use them.

@jiahao jiahao closed this as completed Apr 20, 2015
vtjnash added a commit that referenced this issue Jun 3, 2015
@vtjnash
make start_reading/stop_reading automatic exactly when needed. fix #1925
9de4a9a 
, fix #10655 (closes #11530)

this also makes the read throttle more intelligent so that it doesn't
get tripped up by wait_nb requests for more than READ_BUFFER_SZ bytes
vtjnash added a commit that referenced this issue Jun 3, 2015
@vtjnash
make start_reading/stop_reading automatic exactly when needed. fix #1925
63cda45 
, fix #10655 (closes #11530)

this also makes the read throttle more intelligent so that it doesn't
get tripped up by wait_nb requests for more than READ_BUFFER_SZ bytes
@vtjnash vtjnash mentioned this issue Jun 3, 2015
Merged
vtjnash added a commit that referenced this issue Jun 4, 2015
@vtjnash
make start_reading/stop_reading automatic exactly when needed. fix #1925
53b4704 
, fix #10655 (closes #11530)

this also makes the read throttle more intelligent so that it doesn't
get tripped up by wait_nb requests for more than READ_BUFFER_SZ bytes
vtjnash added a commit that referenced this issue Jun 4, 2015
@vtjnash
make start_reading/stop_reading automatic exactly when needed. fix #1925
863e3dd 
, fix #10655 (closes #11530)

this also makes the read throttle more intelligent so that it doesn't
get tripped up by wait_nb requests for more than READ_BUFFER_SZ bytes
vtjnash added a commit that referenced this issue Jun 6, 2015
@vtjnash
make start_reading/stop_reading automatic exactly when needed. fix #1925
5863b48 
, fix #10655 (closes #11530)

this also makes the read throttle more intelligent so that it doesn't
get tripped up by wait_nb requests for more than READ_BUFFER_SZ bytes
@kmsquire kmsquire mentioned this issue Jun 11, 2015
Merged
@djoshea djoshea mentioned this issue Dec 17, 2015
Closed
amitmurthy added a commit that referenced this issue Jan 11, 2016
@amitmurthy
Revert "make start_reading/stop_reading automatic exactly when needed. …
9e19627 
…fix #1925, fix #10655 (closes #11530)"

This reverts commit 5863b48.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Keno Keno

Labels
domain:io Involving the I/O subsystem: libuv, read, write, etc.
Projects
None yet
Milestone
0.4.0
Development

No branches or pull requests
4 participants
@jiahao @vtjnash @JeffBezanson @Keno