Skip to content

fix: use global fortran lock instead of per-library#103

Merged
greglucas merged 2 commits into
SWxTREC:mainfrom
greglucas:global-msis-lock
Jun 28, 2026
Merged

fix: use global fortran lock instead of per-library#103
greglucas merged 2 commits into
SWxTREC:mainfrom
greglucas:global-msis-lock

Conversation

@greglucas

Copy link
Copy Markdown
Member

We are sharing Fortran SAVE state and other global things and using a shared library too, so we need to raise the lock up to the top-level and not try to optimize it for individual libraries. There are likely few people who need the per-library performance benefit.

We are sharing Fortran SAVE state and other global things and using
a shared library too, so we need to raise the lock up to the top-level
and not try to optimize it for individual libraries. There are likely
few people who need the per-library performance benefit.
@greglucas greglucas merged commit 5819748 into SWxTREC:main Jun 28, 2026
38 checks passed
@greglucas greglucas deleted the global-msis-lock branch June 28, 2026 18:32
@greglucas

Copy link
Copy Markdown
Member Author

Note the real impactful change here was zero-initializing the arrays entering Fortran, it seems like that might not be safe in the Python <-> Fortran bridge layer and some unitialized values get used somewhere only occasionally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant