You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From @cshenry...
It has a few ramifications:
1.) To avoid race conditions, I only want to allow one gapfilling operation to run at a time. To enforce this, we'll need some sort of "locking" mechanism (which is always a pain, but necessary).
2.) Integration and unintegration of gapfillings will be much slower than they are now...
3.) "list_models" and "get_model" will be much much faster... and more reliable.
The text was updated successfully, but these errors were encountered:
Sounds fair enough. In the future, it seems like a gapfill should run on a
'version' of the model that was input (rather than modify the model object
directly) and that two parallel gapfills should spin off parallel versions
that could then be merged later. Something for the future projects list.
From @cshenryhttps://github.com/cshenry...
It has a few ramifications:
1.) To avoid race conditions, I only want to allow one gapfilling
operation to run at a time. To enforce this, we'll need some sort of
"locking" mechanism (which is always a pain, but necessary).
2.) Integration and unintegration of gapfillings will be much slower than
they are now...
3.) "list_models" and "get_model" will be much much faster... and more
reliable.
—
Reply to this email directly or view it on GitHub #91.
Sorry I forgot this ticket.
From @cshenry...
It has a few ramifications:
1.) To avoid race conditions, I only want to allow one gapfilling operation to run at a time. To enforce this, we'll need some sort of "locking" mechanism (which is always a pain, but necessary).
2.) Integration and unintegration of gapfillings will be much slower than they are now...
3.) "list_models" and "get_model" will be much much faster... and more reliable.
The text was updated successfully, but these errors were encountered: