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.

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

Somehow the server always spawn at least 2 threads. #425

Closed
elichai opened this issue May 1, 2019 · 2 comments · Fixed by #495
Closed

Somehow the server always spawn at least 2 threads. #425

elichai opened this issue May 1, 2019 · 2 comments · Fixed by #495

Comments

@elichai
Copy link

elichai commented May 1, 2019

If I don't mention the amount of threads or if I put .threads(1) I still see that there are 2 different threads operating.
Example code:

use jsonrpc_http_server::jsonrpc_core::*;
use jsonrpc_http_server::*;
use std::thread::{self, current, JoinHandle};

use jsonrpc_client_http::HttpTransport;
use jsonrpc_client_core::{jsonrpc_client, expand_params};


fn main() {
    let server = launch_server();
    thread::sleep(std::time::Duration::from_secs(5));

    let handles = send_requests(10);
    let results: Vec<_> = handles.into_iter().map(|h|h.join().unwrap()).collect();
    println!("{:?}", results);


}

fn launch_server() -> Server {
    let mut io = IoHandler::new();
    io.add_method("say_hello", |_: Params| {
        println!("I'm in thread ID: {:?}, name: {:?}", current().id(), current().name());
        Ok(Value::String("hello".to_string()))
    });

    let server = ServerBuilder::new(io)
        .threads(1)
        .start_http(&"127.0.0.1:3030".parse().unwrap())
        .unwrap();
    server
}



jsonrpc_client!(pub struct KeyManagementClient {
    pub fn say_hello(&mut self) -> RpcRequest<Value>;
});

fn send_requests(n: usize) -> Vec<JoinHandle<Value>> {
    let mut handles = Vec::with_capacity(n);
    for _ in 0..n {
        let handle = thread::spawn( || {
            let transport = HttpTransport::new().standalone().unwrap();
            let transport_handle = transport.handle("http://127.0.0.1:3030").unwrap();
            let mut client = KeyManagementClient::new(transport_handle);
            client.say_hello().call().unwrap()
        });
        handles.push(handle);
    }
    handles
}

Output:

I'm in thread ID: ThreadId(2), name: Some("jsonrpc-eventloop-0")
I'm in thread ID: ThreadId(3), name: Some("jsonrpc-eventloop-1")
I'm in thread ID: ThreadId(2), name: Some("jsonrpc-eventloop-0")
I'm in thread ID: ThreadId(3), name: Some("jsonrpc-eventloop-1")
I'm in thread ID: ThreadId(3), name: Some("jsonrpc-eventloop-1")
I'm in thread ID: ThreadId(2), name: Some("jsonrpc-eventloop-0")
I'm in thread ID: ThreadId(3), name: Some("jsonrpc-eventloop-1")
I'm in thread ID: ThreadId(2), name: Some("jsonrpc-eventloop-0")
I'm in thread ID: ThreadId(3), name: Some("jsonrpc-eventloop-1")
I'm in thread ID: ThreadId(2), name: Some("jsonrpc-eventloop-0")
[String("hello"), String("hello"), String("hello"), String("hello"), String("hello"), String("hello"), String("hello"), String("hello"), String("hello"), String("hello")]

As You can see there's threadID 2 and 3, (jsonrpc-eventloop-0 and jsonrpc-eventloop-1) both operate within the code of the server.

cc #423 @tomusdrw

@elichai
Copy link
Author

elichai commented Jul 12, 2019

@tomusdrw ?

@tomusdrw
Copy link
Contributor

Indeed, seems that during switch to tokio configuring .threads is basically useless or at least doesnt' work correctly.

  • serve function that in the original design was supposed to be running an event loop and block the thread is currently just spawning a task to executor.
  • Executor is configured to run in number of threads that depend on number of cores and for your system it seems to be 2.
  • And we also start a completely useless thread that just waits for the tokio::runtime to finish when we spawn the Reactor.
    runtime.shutdown_on_idle().wait().unwrap();

I'll try to look into it and clean it up a bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants