Get the PID of the root supervisor

Hi all,

I have short-lived test processes that use an ETS table for storing state. When they die, the table is dropped.

I’d like to set the root supervisor process as the table’s heir so that the ETS table is not dropped during the whole testing process. How can I get its PID ?

I also know that I could set up the table upon test or application startup, but I’m looking for a less intrusive solution. More specifically, I want to implement everything in one file of an implementation of a behaviour without modifying the rest of the app.

Cheers!

Don’t this is very bad idea for few reasons:

  • Storing state between tests mean that you are bounded to the order in which tests happen
  • It prevents tests from running in async manner
  • It can blow your VM up when there will be too much ETS tables (earlier there was a limit, now it can munch RAM)

What is the reason for such task? Because it feels like XY problem.

2 Likes

Main reason is curiosity.

I’m not sure yet if I’ll need this eventually, and I’m not talking only about unit tests but running a test suite against a REST API while using the default “test” implementation of the persistence layer. And I’d like to have the whole implementation, including setting up the ETS table, in the test behaviour implementation file. That said, I’m curious if there’s a better and cleaner way to do it.

Also, this is a named table and the idea is to create it if it doesn’t exist without init in application.ex for instance. Yes, this is one more lookup and inefficient but it won’t end up in prod anyway. and won’t blow up the VM - no more than 1 table is to be created.

Traditionally you create a dedicated GenServer process in your application’s supervision tree to be the owner of the table if you want it to persist indefinitely.

3 Likes

Thanks for the answer, that’s indeed the way to go for a clean implementation.

However, I’m talking about a library without the application callback. In this library, I define a behaviour and I’d like to provide a default test implementation as well that doesn’t require additional configuration (such as “add {MyModuleImpl, [opt1, opt2...] to your application.ex to start it under your supervision tree”). In a nutshell, I’d like to have a zero-conf implementation, be it an ugly hack.

Actually I’ve thought of starting an unlinked named process, that should work but I’m still genuinely interested out of curiosity whether there’s way to retrieve the pid of the root supervisor :slight_smile:

I think it’s always 0.0.0.

Process.whereis(:init) will get you to it too.

1 Like

but seriously, don’t link an ets table to it.

2 Likes