Are global functions need to be accessed in separate processes?

Questions
#1

Hi

In relation to the Rust binding that I’m working on for some time, I’ve got in a situation that running unit tests for accessing a globally registered function and registering a global function causes some trouble that cargo test (even with --test-threads=1) makes sometimes some tests fail or pass underministically (even with locking a mutex for each test). However, running tests individually cargo test my_func is fine and it should be possible to automate this in the worst case.

  1. @tqchen I just want to confirm this and would like to know more details of the inner working of global functions? and whether it’d be possible to make the threads sanitized which they’re not now!

  2. @jroesch, @nhynes I’d like to know your opinion about it and have you encountered such problems before?

#2

This is a somewhat common problem I’ve found when testing Rust, especially when using lazy_static. Unfortunately, the TVM compiler wasn’t really designed to handle multi threading. Even the runtime was only recently fixed to support concurrent graphs. What global functions are you having trouble with?

On an unrelated note, are you sure you really want to copy over that pattern of globals? Getting rid of those was one of the reasons I wrote the Rust runtime :slight_smile:

#3

I agree that globals are evil, but limited globals should be helpful, and especially in the case of system functions registries.

#4

Right! since I want to keep compatible frontend functionalities across, I’m going for registering global callbacks. When I register a constant “zero” function for example, in unit test “register_zero”, cargo test or cargo test function (testing function.rs module) fails but cargo test register_packed passes.

#5

Thank you @nhynes and @tqchen for your comments. So I’ll think about a work around solution for testing function.rs unit tests individually, until something changes in the backend.