Am 27.11.2023 um 11:19 schrieb David Brown:

> No, I said that most of the standard library is useless for the work
> I do, but useful for other people.  And I've said that exceptions
> can be useful (but not for my work), but are not the kind of wonderful
> universal "clean" failure handling mechanism you seem to believe.

That's a matter of opinion. I'm not a painful person like you and I
think error handling in C++ with exceptions and RAII is great relief
over manual return code handling and no RAII. With that error handling
is just catching errors in a central place and reporting that error;
that's not much work compared to C.

On 11/27/2023 12:34 AM, Bonita Montero wrote:
> Am 27.11.2023 um 09:28 schrieb Chris M. Thomasson:
>
>> On 11/26/2023 11:57 PM, Bonita Montero wrote:
>
>>> I told you twice that this would make sense if you additionally would
>>> wait for some other waitable kernel objects. If the IOCP is signalled
>>> you'd do an additional GQCS() on the IOCP. This actually works with
>>> Windows 11 and it would be nice if MS would document since which Win-
>>> dows version it is safe to have a WFMO() on a IOCP.
>
>> This is undocumented behavior, and I am not sure what benefit it would
>> have anyway. ...
>
> If you can imagine the benefit of waiting for multiple kernel objects
> you can also imagine the benefit of waiting multiple kernel objects
> where at least one object is an IOCP.

You should send some emails to Microsoft. Be double sure to show them
how you behave here...

>
>> https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects
>> ________________
>> When bWaitAll is TRUE, the function's wait operation is completed only
>> when the states of all objects have been set to signaled. The function
>> does not modify the states of the specified objects until the states
>> of all objects have been set to signaled. For example, a mutex can be
>> signaled, but the thread does not get ownership until the states of
>> the other objects are also set to signaled. In the meantime, some
>> other thread may get ownership of the mutex, thereby setting its state
>> to nonsignaled.
>> ________________
>
> You can probably just as easily imagine that I don't mean the case
> where we wait for all objects to signal, but only one of them. So
> I don't understand why you're so misunderstanding what I said.

On 11/27/2023 12:34 AM, Bonita Montero wrote:
> Am 27.11.2023 um 09:28 schrieb Chris M. Thomasson:
>
>> On 11/26/2023 11:57 PM, Bonita Montero wrote:
>
>>> I told you twice that this would make sense if you additionally would
>>> wait for some other waitable kernel objects. If the IOCP is signalled
>>> you'd do an additional GQCS() on the IOCP. This actually works with
>>> Windows 11 and it would be nice if MS would document since which Win-
>>> dows version it is safe to have a WFMO() on a IOCP.
>
>> This is undocumented behavior, and I am not sure what benefit it would
>> have anyway. ...
>
> If you can imagine the benefit of waiting for multiple kernel objects
> you can also imagine the benefit of waiting multiple kernel objects
> where at least one object is an IOCP.
[...]

No need for it at all. Well, at least is none of my server work.

On 11/26/2023 4:54 AM, David Brown wrote:
> On 26/11/2023 00:29, Michael S wrote:
>> On Sat, 25 Nov 2023 19:30:03 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>> On 2023-11-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Am 24.11.2023 um 19:33 schrieb Kaz Kylheku:
>>>>>> It's just a syntactic sugar to avoid forgetting to unlock ...
>>>>>
>>>>> RAII is magnitudes more convenient and lass error-prone
>>>>> than manual resource handling.
>>>>
>>>> Sure, but that's not necessarily an effective way to "sell" it to
>>>> someone who is being skeptical.
>>>
>>> I would argue that is is not 'less error-prone' than
>>> explicit locking, properly written and unit tested.
>>
>> RAII is horrible, but unfortunately necessary in big undisciplined C++
>> projects.
>> The root bug in C++ language design are constructors that can fail, but
>> can't return error code.
>
> That's easily solved in cases like this - write constructors that can't
> fail.
>
> In the kind of systems I work with, something like acquiring a mutex
> cannot fail unless there is a major system failure that renders it
> unsafe to run anything - the system then turns off all the machinery it
> controls, logs everything it can, and alerts the user to the failure.
> That applies equally to a free-standing "lock" function or an RAII
> constructor solution.  There is no need for exceptions, error codes, or
> anything of that sort.
>
>> That problem begot exceptions. And the presence of exceptions begot
>> RAII. RAII is bad, but less bad than other solutions.
>>
>
> I am not a fan of exceptions in low-level code or control code.  They
> are fine in high-level PC stuff when dealing with things that can
> reasonably fail but where you don't want to bother with all the details
> all the time - such as a constructor for opening a handle to a database.
>  (I mostly use Python for that kind of thing anyway, but that's just
> personal choice.)
>

> Once you stop thinking that code can fail, and write code that doesn't
> fail, it all becomes much easier,

Amen. :^)

> and RAII is just another useful tool.
> (And you can compile with exceptions fully disabled.)
>

On 11/26/2023 2:35 AM, Bonita Montero wrote:
> Am 26.11.2023 um 00:06 schrieb Chris M. Thomasson:
>
>> Huh? Drill down on that. What do you mean wrt "_after_ you waited"?
>
> If you want to wait mor than on the IOCP itself you could use WFMO
> and if the IOCP was signalled GQCS afterwards. With an IOCP you can
> wait only for the IOCP and maybe an alert if you use GQCSE.
>
>> So your hack can break at any time? ...
>
> It would be nice if MS would document since when this works.
>
>> So your hack can break at any time? Keep in mind that I said GQCSEX...
>> :^) Its more efficient that GQCS. ...
>
> It's not about the efficiency but that you could be signalled other
> waitable kernel objects also.
>

God knows what WFMO is going to do to that IOCP handle. It could break
things at a lower level of logic.

On 11/16/2023 9:45 AM, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 16.11.2023 um 16:02 schrieb Scott Lurndal:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 15.11.2023 um 21:08 schrieb Chris M. Thomasson:
>>>>
>>>>> Are you sure its 100% atomic for use in multi-thread sync algorithms?
>>>>
>>>> If MSVC generates that code it's atomic.
>>>
>>> No, if Intel architecture documentation specifies that it is
>>> single-copy atomic, then it is single-copy atomic.
>>
>> MSVC relies for sure on the right behaviour.
>
> Right. Keep thinking that.
>
>>
>>> MSVC is just a poor-to-middling C compiler.
>>
>> MSVC has the strongest C++20-conformance but the weakest optimizer.
>
> Faint praise, indeed. Nobody other than Herb cares about C++20 conformance.

;^D Sutters mill...

>
> Most real world C++ code relies on C++11 for portability. Most
> of our systems and our customers systems don't even support C++17.
>

On 28/11/2023 00:15, Chris M. Thomasson wrote:
> On 11/26/2023 4:54 AM, David Brown wrote:

>
>> Once you stop thinking that code can fail, and write code that doesn't
>> fail, it all becomes much easier,
>
> Amen. :^)

It would probably have been better to say "Once you stop thinking that
code always has the possibility of failure, you can start writing code
that cannot fail." Code can still fail - you might have made a mistake
in the code. But then it is /your/ fault, as the programmer - take
responsibility for that, don't punt it down the line as an exception to
the innocent programmer that calls your function.

If it is inevitable that your function might not be able to do its main
job - it's trying to read a file that might not exist, or connect to a
database that might not be online - make such failures explicitly part
of the specification of the function.

Maybe you think exceptions are the best way to communicate such
failures. Then your specification is "This function reads the file and
returns its contents, or throws a FileNotAccessible exception". The
real trouble with the whole concept of exceptions is that people think
they mean you can specify the function as "This function reads the file
and returns its contents", and that somehow exceptions magically fix any
failures, or that code further up the food chain can compensate for the
problem - and no one takes responsibility. Error code return can be
ugly, and std::expected<> returns can mean changing lots of code along
the way, but these make the failures /explicit/ - you have to keep
looking at them until you deal with them. They are part of the
specification of the code, not an afterthought that magically floats
around until it gets swept under the carpet.

>
>
>> and RAII is just another useful tool. (And you can compile with
>> exceptions fully disabled.)
>>
>

On 11/27/2023 3:19 PM, Chris M. Thomasson wrote:
> On 11/26/2023 2:35 AM, Bonita Montero wrote:
>> Am 26.11.2023 um 00:06 schrieb Chris M. Thomasson:
>>
>>> Huh? Drill down on that. What do you mean wrt "_after_ you waited"?
>>
>> If you want to wait mor than on the IOCP itself you could use WFMO
>> and if the IOCP was signalled GQCS afterwards. With an IOCP you can
>> wait only for the IOCP and maybe an alert if you use GQCSE.
>>
>>> So your hack can break at any time? ...
>>
>> It would be nice if MS would document since when this works.
>>
>>> So your hack can break at any time? Keep in mind that I said
>>> GQCSEX... :^) Its more efficient that GQCS. ...
>>
>> It's not about the efficiency but that you could be signalled other
>> waitable kernel objects also.
>>
>
> God knows what WFMO is going to do to that IOCP handle. It could break
> things at a lower level of logic.

Nt 4.0 source code is out there. Humm... So, you should dig into it and
see what happens to IOCP if you pass its handle to WFMO...

On 11/14/2023 5:42 PM, Pavel wrote:
> Kaz Kylheku wrote:
>> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>
>> wrote:
>>> "as-if" and "according to the scheduling policy (if applicable)" here
>>> are important. The standard intent may be to permit only the threads
>>> that are "unblocked" contend for the mutex -- as opposed to all
>>> non-blocked threads.
>>
>> It's possible that only one thread is unblocked by a
>> pthread_cond_signal. It takes at least two parties to contend for
>> something.
>>
> My point was that the "unblocked" thread could be the thread that "won"
> the contention. "as-if" there meant that the threads didn't really need
> to be all woken up / unblocked and start contending; but the contention
> could be resolved according to the scheduling policy (the same one that
> would be applied if they were actually running and contending for the
> mutex, without any waiting for the condvar) within the signal call.

The flexibility of the API allows us to signal inside and/or outside of
a locked mutex region. So, whats the problem?