[
https://issues.apache.org/jira/browse/LUCENE-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105685#comment-13105685
]
Yonik Seeley commented on LUCENE-3439:
--------------------------------------
I think the open/closed checks should still be non-volatile.
While a volatile read on (current) x86 is a no-op, it still imposes a
happens-before/after restriction via the memory model and hence prevents
optimizations across that volatile read. Volatile reads may not always be a
no-op on x86 either (and they already aren't on other CPUs).
Using a volatile also doesn't buy us much either - it's still best-effort (the
close could come after we have checked the volatile, but before we have done
the read). We have enough volatile/synchronized reads in other places that a
non-volatile check will suffice to catch bugs (and we shouldn't penalize
correct programs).
> add checks/asserts if you search across a closed reader
> -------------------------------------------------------
>
> Key: LUCENE-3439
> URL: https://issues.apache.org/jira/browse/LUCENE-3439
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: LUCENE-3439_test.patch
>
>
> if you try to search across a closed reader (and/or searcher too),
> there are no checks, not even assertions statements.
> this results in crazy scary stacktraces deep inside places like FSTs/various
> term dictionary implementations etc.
> In some situations, depending on codec, you wont even get an error (i'm sure
> its fun when you try to retrieve the stored fields!)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
