# Where do DistributeDefinitions and ParallelNeeds put their definitions for newly-launched kernels to find

I'm sorry to keep banging on the definition distribution bell, but here is another (hopefully well-focused enough) question on that vein.

If one is trying to distribute the definitions in a package to the subkernels that will perform a parallel computation, there are several options for it, most prominently DistributeDefinitions and ParallelNeeds. One of the features explained in their documentation is that the definitions they distribute are made available to any new kernels that might get started after the distribution. This could be because a kernel dies and is respawned halfway through a calculation, or simply because DistributeDefinitions gets called before LaunchKernels.

In particular, then, the documentation promises that

DistributeDefinitions in effect "registers" the definitions for the symbols $s_i$ so that they are automatically distributed to every new parallel kernel that may be launched.

and that

ParallelNeeds in effect "registers" Needs specifications so that they are automatically performed in every new parallel kernel that may be launched.

This is in contrast to ParallelEvaluate[Needs[...]], which as opposed to ParallelNeeds will (i) not start new kernels, and (ii) not pass the definitions to any kernels started after the command is evaluated.

The documentation, though, is pretty mysterious on the details of how these two functions manage to "register" the stuff they're distributing; my question, therefore, is how this happens internally. To put this on a more concrete, footing, though, I'm happy to accept as an answer a description of the 'register' where the definitions are stored, and how it could be accessed by the user.

• What do you hope to achieve by accessing such a register (if, indeed, it is accessible through top-level code)? – MarcoB May 4 '16 at 3:02
• @MarcoB Mostly just understanding ;-). It's more in terms of knowing what is and is not already on that register, as well as understanding what happens when a new subkernel is launched and where it gets its kernel state from. – Emilio Pisanty May 4 '16 at 10:58