> > *** pthread_attr_destroy(), p 981
> >
> > @31291-31294
> >
> > Add:
> >
> > The pthread_attr_init() may fail if:
> > [EINVAL] The value specified by attr is invalid.
> >
> Um, that would be bad. One does not normally expect to be initializing a
> valid object, so this would suggest failure in the only case where one
> ought to be applying the interface! ;-)
Well, I was also a bit surprised to see that text in the barrier, mutex, cv,
rwlocks... I understood it that way: "the address stored in attr is
invalid",
since attr is a pointer and thus "the value of attr" is an address.
Ok, from an implementation point of view this means checking attr==NULL, or
eventually (if extremely user friendly) checking that the pointer refers to
a
valid memory address within the process.
However, I agree with Ulrich (ERN 136) that the formulation is not really
clear. The question is: how should we understand the sentence:
"The value specified by attr is invalid". ??
Don't you think that interpreting as "the object referred by attr is
invalid"
could be a bit overstated? (unless you know exactly what was intended).
Anyway, that's definitively confusing and _must_ be reworded.
> In fact, I'm a little surprised to see that only ENOMEM is documented. I
> thought we had also had a "may fail" EBUSY if 'attr' refers to an
> initialized thread attribute object.
This would be reasonable, indeed. For at least one reason: I expect some
implementations to allocate a structure on the heap. Re-iniatilizing an
attr,
would likely lead to a memory leak.
So yes, I agree with you: this would be a nice OPTIONAL feature.
> (We don't, though, for attr, mutexattr, or condattr. Huh.)
As stated in the beginning: "I tried to be consistent with the
descriptions of those synchronization devices"... So, if the description for
those devices is inconsistent, the proposed description is equally
inconsistent (and that's consistent ;-).
If we're gonna to update this for attr, we have to update also for the
barrier,
mutex, cv, and rwlocks I guess.
> Regardless of the outcome of ERN136 (which should be "ACCEPT" ;-) ), I
> recommend that we start out correctly here by making any invalid attr
> detection returns MAY FAIL.
Ok.
> In any case, while Ultrich's suggested rephrasing from
> "the value specified by attr" to "the attributes specified by attr" makes
> sense for pthread_create(), it really doesn't here.
Exactly. See my thoughts.
> The init and destroy functions don't deal with individual attributes but
> with the entire attributes object.
Yes.
> > *** pthread_attr_getinheritsched(), p 988
> >
> >@31516 Change "may" to "shall" [[??? I believe, it is well defined?? ]]
> >
> Yes, "the value of inheritsched is not valid" should be well defined.
> However, to present a bad scalar value to the interface is also a
> programming error.
Ah! I missed that fundamental point :-)
> In general I'm more reluctant to accept converting
> "MAY FAIL" to "SHALL FAIL" than vice versa, because it's a burden to
> existing implementations that don't check... and the "SHALL FAIL" is no
> help to conforming applications unless they INTEND to fail. ;-)
You're right. The "may" is fine here.
> I think we ought to remove the ENOTSUP if we're cleaning up -- unless
> someone can recall why it was there and offer some rationale. ;-)
>
> PTHREAD_INHERIT_SCHED and PTHREAD_EXPLICIT_SCHED must be supported. So
> ENOTSUP could apply only to non-standard additional inheritsched codes.
> (And I still can't imagine how any could be reasonable and valid; but
> nevermind that.)
Agree. In came to the same conclusion in a post from yesterday. The only
plausible explanation I found for leaving this interface open is:
"for future extensions" that we haven't foreseen yet...
> This error code presupposes that it's OK for an
> implementation to define nonstandard codes that it doesn't support.
> Dumb. But even with that... the standard never precludes adding
> additional error codes for additional conditions not covered by the
> standard. Without extensions, or even with reasonable extensions,
> ENOTSUP has no purpose here.
Ok, then let's ditch ENOTSUP!
> >*** pthread_attr_getscope(), p 994
> >
> > @31653 rewording, maybe???
> > [[ Is the term "may have" infortunate, or don't I master English well
> > enough? I guess, the 2nd case :-) ]]
> >
> Technically, "may" refers to optional implementation behavior. The
> standard requires that the implementation provide PTHREAD_SCOPE_PROCESS,
> PTHREAD_SCOPE_SYSTEM, or both. I suspect that the "may" is intended to
> suggest that the application cannot count on any particular value being
> supported. However, both symbols shall be DEFINED. Actually, while in
> many places the "shall"/"may" wording was carefully IMPROVED between
> 1003.1a-1995 and XSH, this appears to have gone the other way. POSIX
> says that "The symbols PTHREAD_SCOPE_SYSTEM and PTHREAD_SCOPE_PROCESS
> shall be defined" while XSH says weakly that they "are defined". This
> should be fixed.
Ok.
> As for the "contentionscope attribute may have the values"... hmm. I'm
> not entirely sure I like the wording -- but I don't have a better
> alternative, and I'm not sure there's anything wrong. The application
> indeed MAY supply either value for contentionscope.
Ok, fine.
> If the implementation doesn't support that value, it'll fail with ENOTSUP.
> In any case, the implementation is clearly required to define both values.
Which in this case makes sense...
> > *** pthread_attr_getstackaddr(), p 998
> >
> > @31760-31762
> >
> > [[ What? No error defined? I would leave this "as is", first for
> > backward compatibility and second because it is marked as
> > "obsolescent"]]
> >
> We could get these for consistency, or not bother. The standard doesn't
> preclude an implementation from detecting and reporting EINVAL here,
> even though it's not documented explicitly.
I like consistency :) Even if this case, it means "more work".
> > [[ Why is this function not marked as "obsolescent"?? I would
> > understand that pthread_attr_{get|set}stack generalize BOTH
> > stackaddr and stacksize ??? Does it have to do with TSA??? ]]
> >
> (TSA??) The stacksize and guardsize attributes apply to stacks allocated
> and managed by the IMPLEMENTATION. The stack and stackaddr attributes
> apply to stacks allocated and managed by the APPLICATION.
Ah... I missed that fundamental difference. Thanks for the explanations.
Loic.
--
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
|