Fineweb sharding multi-process bugfix

[GrahamTheCoder]

Previous observed behaviour

(On my windows machine with 4+ logical processors)

                                                                                                     | 0/1630 [00:00<?, ?it/s]Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\spawn.py", line 116, in spawn_main
    exitcode = _main(fd, parent_sentinel)
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\spawn.py", line 125, in _main
    prepare(preparation_data)
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\spawn.py", line 236, in prepare
    _fixup_main_from_path(data['init_main_from_path'])
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\spawn.py", line 287, in _fixup_main_from_path
    main_content = runpy.run_path(main_path,
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\runpy.py", line 289, in run_path
    return _run_module_code(code, init_globals, run_name,
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\runpy.py", line 96, in _run_module_code
    _run_code(code, mod_globals, init_globals,
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\Users\me\source\repos\llms-from-scratch\build-nanogpt\fineweb.py", line 46, in <module>
    with mp.Pool(nprocs) as pool:
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\context.py", line 119, in Pool
    return Pool(processes, initializer, initargs, maxtasksperchild,
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\pool.py", line 215, in __init__
    self._repopulate_pool()
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\pool.py", line 306, in _repopulate_pool
    return self._repopulate_pool_static(self._ctx, self.Process,
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\pool.py", line 329, in _repopulate_pool_static
    w.start()
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\process.py", line 121, in start
    self._popen = self._Popen(self)
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\context.py", line 336, in _Popen
    return Popen(process_obj)
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\popen_spawn_win32.py", line 45, in __init__
    prep_data = spawn.get_preparation_data(process_obj._name)
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\spawn.py", line 154, in get_preparation_data
    _check_not_importing_main()
  File "C:\Users\me\.pyenv\pyenv-win\versions\3.10.9\lib\multiprocessing\spawn.py", line 134, in _check_not_importing_main
    raise RuntimeError('''
RuntimeError:
        An attempt has been made to start a new process before the
        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your
        child processes and you have forgotten to use the proper idiom
        in the main module:

            if __name__ == '__main__':
                freeze_support()
                ...

        The "freeze_support()" line can be omitted if the program
        is not going to be frozen to produce an executable.

Implementation details

The error message itself and docs seem pretty clear that this is the pattern to use, and I can confirm it worked for me - it even nicely resumed, managing to save out the shards without redownloading. I'm not a python expert, so if there's a better way, then by all means do it.
I've currently decided to omit the freeze_support() call in this case since I haven't tested it and other changes may be needed to get frozen windows exes working.

Reviewing

I've split the extract method with indentation change from the behaviour change, if you view ignoring whitespace you can see it's a pretty simple change

Many thanks for the video series and code!

[GrahamTheCoder]

I'll close this since it's functionally equivalent to #4
Not sure how I missed that