4

I need to run my client application (written in c++ with gRPC) in an operating system (which only support single thread). However, I noticed that grpc::InsecureChannelCredentials(); is trying to create multiple threads. Here is the output from debugger after calling that gRPC function in my host machine:

[New Thread 0x7ffff524a700 (LWP 3709)]
[New Thread 0x7ffff524a700 (LWP 3710)]
[New Thread 0x7ffff524a700 (LWP 3711)]

This will cause the program crash inside the single thread OS.

My question is: is there a way to configure gPRC using only single thread, or make cpp executable run only with single thread? Thanks in advance.

btw, here is the link to the os mentioned above and the issue explains why it only support single thread. https://github.com/lsds/sgx-lkl/issues/1

EDIT: It's actually not allowing multi-process instead of multi-thread applicaiton. gRPC seems like doing fork inside its core lib. I'm wondering if there is a way to configure gRPC to disable process forking.

J.Z
  • 411
  • 3
  • 14
  • If the OS only supports single threaded applications, how does the application manage to create multiple threads? That seems like *quite* a trick. One might almost think that the OS supports multiple threads, since it lets the application create them... Something in your question doesn't add up. – Jesper Juhl Mar 13 '19 at 19:16
  • The executable is compiled with `-pie` flag from my host machine, and I am trying to make the executable running inside OS running in a container. My host machine is running ubuntu which the program does not cause any problem. But it will crash when running in the container. – J.Z Mar 13 '19 at 19:28
  • How is `-pie` relevant? That has *nothing* to do with the number of threads. That only affects your address space layout and whether your application is dynamically relocatable or not. – Jesper Juhl Mar 13 '19 at 19:30
  • I know. My point is that the reason of why app create multi threads inside that os is because I initially compiled it in my host machine. – J.Z Mar 13 '19 at 19:34
  • how is where it is compiled relevant? It either creates multiple threads or it does not. Where/how it was compiled does not influence that. – Jesper Juhl Mar 13 '19 at 19:35
  • @JesperJuhl The test case presented above is run in one environment. OP is concerned that there will be problems when it's deployed on another target environment that doesn't allow new threads to be created. – François Andrieux Mar 13 '19 at 19:38
  • From my understanding, creating threads makes the program out of the sgx enclave(environment from the link in question), which caused the problem. And that's why I want to prevent the executable creating threads. – J.Z Mar 13 '19 at 19:40
  • @FrançoisAndrieux then OP should make his software *not* create multiple threads. What more is there to say? – Jesper Juhl Mar 13 '19 at 19:42
  • @J.Z I'm not an expert on gRPC but RPCs in general usually imply asynchronous execution which is usually implemented by starting unique threads or using a thread pool. My impression is that, unless the framework was specifically designed to work around this problem, it likely relies strongly on the availability of threads. – François Andrieux Mar 13 '19 at 19:42
  • @JesperJuhl OP is using a third party library and is asking how to make it do precisely what you are suggesting. – François Andrieux Mar 13 '19 at 19:42
  • @François Andrieux Thanks for the explanation. Comparing to the rpc server, I feel the blocking due to the single thread for rpc client is acceptable in my case and seems to be the only solution for this os. But I'm not sure if there is a way to do that using gPRC cpp. Anyways, thank you for the help. – J.Z Mar 13 '19 at 19:51
  • @J.Z It may be worth it to investigate whether gRPC is directly requesting threads or if some underlying platform-specific dependency is doing it. If it's the latter, it might just work out of the box for you. Try using a debugger to investigate the entry point for those threads. – François Andrieux Mar 13 '19 at 19:52

0 Answers0