[Documentation] How does `SingleNodeExecutor` touch the file system?
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
- Tipo di issue
- Documentazione
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- documentation, hpc
Direzione di ricerca
Inizia con SingleNodeExecutor, BaseExecutor, DependencyTaskScheduler, OneProcessTaskScheduler e gli strumenti task_scheduler.file indicati nell'issue. Traccia cache_directory da resource_dict attraverso l'invio e l'esecuzione delle attività, quindi documenta il punto in cui viene selezionata la memorizzazione nella cache basata su file e in che modo differisce da create_file_executor. Il lavoro è completato quando il percorso di esecuzione e il collegamento mancante sono spiegati chiaramente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I'm trying to understand where SingleNodeExecutor with a cache_directory gets its instructions to actually write it's result to file.
For instance, consider the following:
from executorlib import SingleNodeExecutor
def foo(x):
return x + 1
with SingleNodeExecutor() as exe:
f = exe.submit(foo, 1, resource_dict={"cache_key": "my_key", "cache_directory": "my_dir"})
print("Result", f.result())
My understanding of the path of events is
Initialization:
SingleNodeExecutor.__init__triggersBaseExecutor.__init__with aDependencyTaskScheduleras its underlying_task_scheduler- That
DependencyTaskScheduleris initialized with aOneProcessTaskScheduleras itsexecutorarg, which gets stored in_process_kwargs["executor"]
Submission:
SingleNodeExecutor.submitis inherited directly fromBaseExecutor.submitBaseExecutor.submitpasses everything (including theresource_dictas a single kwarg) to the_task_scheduler.submit- Since
DependencyTaskScheduler._generate_dependency_graphhas fed through toFalsewith all the default values, this generates the future by a plainsuper()call toTaskSchedulerBase.submit TaskSchedulerBase.submitsends our information (function, args, kwargs, resource dict, empty future) toself._future_queue.put
Here I get out of my depth, but it seems to me like putting stuff on the future queues is activating the associated Thread, which all the TaskSchedulerBase children initialize in _set_process using a Thread taking some function and the _process_kwargs (which includes the _future_queue!). On that assumption, that means that the self._future_queue.put call we got to from TaskSchedulerBase.submit would route back to the Thread set in the DependencyTaskScheduler._set_process invocation -- i.e. _execute_tasks_with_dependencies
Continuing submission:
_execute_tasks_with_dependenciesindeed takes anexecutor, which isDependencyTaskScheduler._process_kwargs["executor"]i.e. ourOneProcessTaskScheduler; there's lots going on, but...- I don't see any reference to the cache, so I don't think the file system interaction is happening here
- It looks like we ultimately do a
executor_queue.putonto the underlyingOneProcessTaskScheduler._future_queue - I.e. we move to
_execute_task_in_separate_process
_execute_task_in_separate_processis in turn re-directing to_wrap_execute_task_in_separate_processand both of these are now taking aspawner: type[BaseSpawner]argument- But I'm at the end of the line, I don't see anything other than the default
MpiExecSpawnerbeing leveraged, and I never find any references to thecache_directoryor any of thetask_scheduler.filemodule tools
With the SlurmClusterExecutor we sometimes route through create_file_executor, in which case the file system connection is obvious, but in the other case we're still going through DependencyTaskScheduler -- this time with an SrunSpawner instead of a MpiExecSpawner. In this later case I also don't see the connection to file system tools, so I feel like I must be missing something at the diverging point: DependencyTaskScheduler.
What am I missing here? When does the SingleNodeExecutor figure out it needs to leverage the "cache_directory" field in the resource_dict?
- Lingua principale
- Python
- Stelle
- 77
- Fork
- 7
- Merge medio
- 10h 32m
- PR unite (30g)
- 12
Preparare l'ambiente
Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di pyiron/executorlib
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
pyiron/executorlib#1054 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
pyiron/executorlib#1032 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
pyiron/executorlib#1005 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
pyiron/executorlib#1049 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
pyiron/executorlib#999 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di pyiron/executorlib
Issue simili
-
good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
vllm-project/vllm-metal#822 ·
I maintainer di solito rispondono entro 1 giorno
-
vector-store
Difficoltà 1/5 1-3 ore Idoneità per principianti 90/100
mem0ai/mem0#7461 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: chunk_span_bounds and _validated_chunk_spans reject Pydantic models ChunkSpan and AudioFileAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
BasedHardware/omi#19047 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno