Conversation
This file is intended to insulate C code from thread issues, when used as directed.
khwilliamson
force-pushed
the
lock_definitions.h
branch
from
0a50c29 to
167d080
Compare
| if $entry->{locks} || $entry->{categories}; | ||
| print $l <<~EOT; | ||
| #${dindent}define ${USE}_LOCK \\ | ||
| #${dindent} error_${use}_not_suitable_for_multi-threaded_operation |
There was a problem hiding this comment.
Why does this generate:
# error_foo_not suitable...
rather than
# error foo_not suitable...
?
The first may produce an error, but it might not include the text of the symbol.
The second will produce the requested message, though it might be better to quote it, which will prevent macro replacement, allowing you to avoid the need for all_the_underscores.
There was a problem hiding this comment.
It turns out that #error may not be the expansion of a macro, and that's why there are all the underscores. But the initial # generates a stray # in program message, so I removed it in #24098
| # previous preprocessor lines. If there was no "#else" line, macros expanding | ||
| # to no-ops are automatically generated for the #else case. | ||
|
|
||
| __DATA__ |
There was a problem hiding this comment.
Two issues, in general:
- This defines a huge number of names most of which will never be used, and have a potential to conflict with names from other libraries.
I think this should add a PERL_ prefix to each lock name.
- This defines separate symbols for each function in a closely related group of functions, for example
dbm_*and any read locale function.
The separate macros imply the need to do each of those locks, even though in some cases it doesn't make sense, eg. if I do a dbm_delete(), I really don't want to release the lock until I do dbm_error().
I think macros should be defined for groups of such functions where it makes sense, eg. a single macro for the dbm_* functions, and just document the need for LC_*_LOCK for locale reading functions etc.
There was a problem hiding this comment.
I share @tonycoz's skepticism as to whether the addition of this header file is necessary or desirable.
There was a problem hiding this comment.
@khwilliamson can you comment on the issues raised by @tonycoz in this ticket back in June?
(My sense is that there's not enough enthusiasm about the patch to warrant keeping this ticket open.)
There was a problem hiding this comment.
I think it could be useful, but it needs some work.
There was a problem hiding this comment.
You can close it, but I will open it again when I finally get around to fixing it up
There was a problem hiding this comment.
Sounds like a plan. Closing ticket for the time being.
jkeenan
added
Closable?
|
#24098 replaces this p.r. |
3 participants
This file is intended to insulate C code from thread issues, when used as directed.