On Mon, Apr 05, 2021 at 10:39:52AM -0700, James Browning wrote:
> [...] our current plan is to implement it with the following syntax:
>
> !include
The reason to favor .include is that lots of other syntaxes use . for
directives, and most people's instinctive interpretation of ! (if any)
is
On Thu, Apr 08, 2021 at 10:47:09AM -0700, Jason Thorpe wrote:
> Is there ANY situation where, for a given pthread condition
> variable, that using a different mutex as the interlock in two
> different calls to pthread_cond_wait() would EVER be legitimate
> usage? I cannot come up with any
>>> Is there ANY situation where, for a given pthread condition
>>> variable, that u$
>> [...] seems to imply that it is permitted, provided the condvar is
>> idle:
> Ah, yes, I should clarify, I am speaking about only when the condition varia$
Then I agree: mixing mutexes then is, at best, an
On Thu 08 Apr 2021 at 11:42:15 -0700, Phil Nelson wrote:
> It appears to me that the code is expecting only one mutex and that it is
> held at cond_wait time and thus should have no problem re-locking the mutex.
The second item ("it is held at cond_wait time") is implied (but not
really spelled
On Thu, 8 Apr 2021 10:47:09 -0700
Jason Thorpe wrote:
> Is there ANY situation where, for a given pthread condition variable, that
> using a different mutex as the interlock in two different calls to
> pthread_cond_wait() would EVER be legitimate usage? I cannot come up with
> any scenario in
> On Apr 8, 2021, at 11:15 AM, Mouse wrote:
>
> I'm curious: why do you care? If, of course, it's anything you can
> talk about.
I have a set of futex-based synchronization objects for libpthread I’ve been
hacking on off-and-on for a while.
-- thorpej
> On Apr 8, 2021, at 11:15 AM, Mouse wrote:
>
>> Is there ANY situation where, for a given pthread condition variable, that u$
>
> For what value of "legitimate"?
>
> I see no reason why this would/should be forbidden, and, indeed, at
> least the 5.2 manpage for pthread_cond_wait seems to
> Is there ANY situation where, for a given pthread condition variable, that u$
For what value of "legitimate"?
I see no reason why this would/should be forbidden, and, indeed, at
least the 5.2 manpage for pthread_cond_wait seems to imply that it is
permitted, provided the condvar is idle:
In article <63f5d53a-2767-48f2-b7fa-fbfe93f63...@me.com>,
Jason Thorpe wrote:
>As far as I can tell, POSIX has no language that covers this situation,
>so Iâm tossing it out here for the hive mind...
>
>Is there ANY situation where, for a given pthread condition variable,
>that using a
As far as I can tell, POSIX has no language that covers this situation, so I’m
tossing it out here for the hive mind...
Is there ANY situation where, for a given pthread condition variable, that
using a different mutex as the interlock in two different calls to
pthread_cond_wait() would EVER
10 matches
Mail list logo
