Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethink how we sleep in StageTask poll() #13

Open
ZNikke opened this issue Mar 12, 2024 · 0 comments
Open

Rethink how we sleep in StageTask poll() #13

ZNikke opened this issue Mar 12, 2024 · 0 comments

Comments

@ZNikke
Copy link
Collaborator

ZNikke commented Mar 12, 2024

In order to allow for dsmc to finish setting attributes etc there is a sleep() in the StageTask poll():

I suspect that this sleep() might be the reason for the somewhat unexpected behavior that the WatchingProvider is so slow, and the observation that the PollingProvider performs much better provided that we allocate a LOT of threads to it.

My reasoning is that although it's a Thread.sleep() it still suspends execution of the thread. This will wreak havoc with the watching provider performance and also increases the likelihood for event overflows. For the polling provider the GRACE_PERIOD of 1000 ms is a direct correlation to the observed performance of the 1-thread-per-Hz of staging performance.

What we really ought to do is something along the lines of:

  • When we see a file with a correct size, add it to a FIFO queue together with the current time.
    • Thus allowing the thread to continue processing.
  • Process the queue whenever we have a file at output that's been sitting there for more than GRACE_PERIOD
    • This can probably be done in lots of ways, the naive approach of checking the queue every 100ms will probably be good enough although there is likely a more elegant Java-ish way to do it. Since this ties in to the magic mess of Futures I'm at a loss what the best method may be.

I believe this would allow threads to do actual work instead of sleeping all the time.

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

No branches or pull requests

1 participant