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.

Sign up for GitHub

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

Jump to bottom

Update rdoc_markup.rb #1318

Merged
merged 1 commit into from
May 3, 2020
Merged

Update rdoc_markup.rb #1318

merged 1 commit into from
May 3, 2020

Conversation

ioquatix
Copy link
Contributor

Don't lazy initialize mutex, ensure mutex is locked when updating associated state.

@ioquatix
Update rdoc_markup.rb
2fc569c 
Don't lazy initialize mutex, ensure mutex is locked when updating associated state.
@coveralls
Copy link

Coverage Status

Coverage remained the same at 93.432% when pulling 2fc569c on ioquatix:patch-1 into 25e77f5 on lsegal:master.

headius
headius reviewed Mar 27, 2020
View reviewed changes
lib/yard/templates/helpers/markup/rdoc_markup.rb
@@mutex ||= Mutex.new
@@mutex.synchronize do
@@formatter ||= RDocMarkupToHtml.new
@@markup ||= MARKUP.new
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these lazy to begin with?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question!

Copy link
Owner

@lsegal lsegal Mar 27, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@headius to minimize memory overhead when the classes might be autoloaded but not necessarily used. Since RDocMarkupToHtml is not owned by YARD (more precisely, the class it inherits is not owned by YARD), there's no reliable way to control how much memory is being wired up when it's initialized.

That said, the case where this file is autoloaded but not used is on the unlikely side, so if there are good reasons to change it, I'm not opposed. I don't see a problem with the change as-is, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it so slow that making one instance per class is out of the question?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late reply @ioquatix: I'm not sure, but these things are instantiated quite often so I would guess the answer is yes. If you want to benchmark to check it out, feel free!

@lsegal
Copy link
Owner

lsegal commented May 3, 2020

Going to take this as is and if we need to touch anything up we can do it in a subsequent PR.

@lsegal lsegal merged commit 601ab79 into lsegal:master May 3, 2020
lsegal added a commit that referenced this pull request May 3, 2020
@lsegal
Tag release v0.9.25
84c983d 
References:
  #1270, #1275, #1301, #1304, #1307, #1308, #1312, #1313,
  #1318, #1320, #1322, #1323, #1324, #1326, #1327
@ioquatix ioquatix deleted the patch-1 branch May 4, 2020 01:43
@ioquatix
Copy link
Contributor Author

ioquatix commented May 4, 2020

Great.

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

@headius headius headius left review comments

@lsegal lsegal lsegal left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@ioquatix @coveralls @lsegal @headius