RFR: 8339475: Check return value of pthread_create in jdk coding

Christoph Langer clanger at openjdk.org
Thu Sep 26 07:10:10 UTC 2024


On Wed, 25 Sep 2024 11:46:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> It has been discussed that checking the return value of pthread_create should be done.
> See the discussion here https://github.com/openjdk/jdk/pull/20812 about the splashscreen coding .

> JLI_ReportErrorMessageSys



> I found some strange handling of the return value on macOS. Here we check already the return value of pthread_create ; but then it seems we add the errno twice when calling JLI_ReportErrorMessageSys, once in the calling params and once in JLI_ReportErrorMessageSys itself. Should we better call with the return value of pthread_create in the error case? Or just with a string without additional parameters? The comment about Solaris 8 is also very outdated, don't think we need that any more in jdk24.
> 
> ```
> src/java.base/macosx/native/libjli/java_md_macosx.m 
> 
> 312     if (pthread_create(&main_thr, NULL, &apple_main, &args) != 0) {
> 313         JLI_ReportErrorMessageSys("Could not create main thread: %s\n", strerror(errno));
> 
> src/java.base/unix/native/libjli/java_md_common.c
> 
> 244  JLI_ReportErrorMessageSys(const char* fmt, ...) {
> 245      va_list vl;
> 246      char *emsg;
> 247  
> 248      /*
> 249       * TODO: its safer to use strerror_r but is not available on
> 250       * Solaris 8. Until then....
> 251       */
> 252      emsg = strerror(errno);
> 253      if (emsg != NULL) {
> 254          fprintf(stderr, "%s\n", emsg);
> 255      }
> ```

Yes, I think the call to java_md_macosx.m seems redundant. And I would remove the comment in java_md_common.c. strerror is used at various places in JDK coding and there's actually only one place that uses strerror_r, in jni_util_md.c

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21182#issuecomment-2376100891


More information about the client-libs-dev mailing list