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.

On 11/24/2023 4:27 PM, Chris M. Thomasson wrote:
> On 11/24/2023 4:08 PM, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
>>>> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>>>>
>>>>>>>>> Which, I would guess, never used by 99.9% of programs that were
>>>>>>>>> not
>>>>>>>>> ported to Windows from some other platform.
>>>>>>>
>>>>>>>> Fwiw, check this out:
>>>>>>>> https://sourceware.org/pthreads-win32/
>>>>>>>
>>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>> That's an unnecessary discussion for a C++ programmer since the
>>>>>>> RAII-ish
>>>>>>> mutexes and condition variables since C++11 are more convenient
>>>>>>> to use.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Have you ever wrapped up a C API in C++ using RAII before?
>>>>>
>>>>> I generally consider using RAII for synchronization primitives
>>>>> to be counterindicated.    Amongst the reasons:
>>>>>    1) The critical sections usually end up being far to large
>>>>
>>>> Use braces?
>>>>
>>>>      {
>>>>         mutex_locker m(obj);
>>>>
>>>>
>>>>      }
>>>
>>> DING!!! :^)
>>
>> No, not really.  It's not always that
>> easy, and sometimes programmers even use 'goto'.
>>
>> That's certainly no more readable than
>>
>>     pthread_lock(obj);
>>
>>     do something
>>
>>     pthread_unlock(obj);
>>
>> I'd argue the RAII solution is less readable.
>
> RAII can come in handy. I don't think its all that bad. Humm...
> _______________________
> {
>    mutex_raii_lock(my_lock);
^^^^^^^^^^^^^

OOPS!
mutex_raii_lock lock(my_lock);

> }
> _______________________
>
> vs:
> _______________________
> my_lock.lock();
> my_lock.unlock();
> _______________________
>
> Btw, wrt C++, RAII tends to work rather well with exceptions... ;^)

On 11/25/2023 11:30 AM, 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.

It can create a dog with different fleas in some cases.

On 11/25/2023 4:04 AM, Bonita Montero wrote:
> Am 25.11.2023 um 00:43 schrieb Chris M. Thomasson:
>
>> How would that even work? You do not need to create an event per
>> connection in IOCP model. IOCP is a different model that is not
>> compatible with WFMO.
>
> You'd have to ask GQCS after you waited.

Huh? Drill down on that. What do you mean wrt "_after_ you waited"?

> Actually WFMO works
> on a IOCP für my Windows 11 PC, but this isn't documented.

So your hack can break at any time? Keep in mind that I said GQCSEX...
:^) Its more efficient that GQCS. Actually, have you ever read a paper
on server design that used cohort scheduling?

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 problem begot exceptions. And the presence of exceptions begot
RAII. RAII is bad, but less bad than other solutions.

On 11/25/2023 3:29 PM, 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.

Horrible? It's not that bad.

> The root bug in C++ language design are constructors that can fail, but
> can't return error code.
> That problem begot exceptions. And the presence of exceptions begot
> RAII. RAII is bad, but less bad than other solutions.
>
>
>

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.

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, and RAII is just another useful tool.
(And you can compile with exceptions fully disabled.)

Am 26.11.2023 um 13:54 schrieb David Brown:

> Once you stop thinking that code can fail, and write code that doesn't
> fail, it all becomes much easier, and RAII is just another useful tool.
> (And you can compile with exceptions fully disabled.)

With exceptions and RAII failures are also very easy to handle because
you handle them only at a few places and not where they happen or in
the call levels between.
Avoiding exceptions looks hard to me because the runtime can throw a
lot of exceptions, mostly bad_alloc()s or system_error()s.

On 26/11/2023 14:38, Bonita Montero wrote:
> Am 26.11.2023 um 13:54 schrieb David Brown:
>
>> Once you stop thinking that code can fail, and write code that doesn't
>> fail, it all becomes much easier, and RAII is just another useful
>> tool. (And you can compile with exceptions fully disabled.)
>
> With exceptions and RAII failures are also very easy to handle because
> you handle them only at a few places and not where they happen or in
> the call levels between.

No, exceptions do not make things easier - they make them /different/.
Sometimes it might be helpful to move failure handling to a different
part of the code, sometimes it makes things harder. Sometimes it is
best to have a failure handling solution that does not care what can
fail, or how it can fail, and only think about failures when you have a
way to deal with them (that's exceptions). Sometimes it is best to be
entirely sure about wait failures can occur at the point of failure, and
deal with them or pass them on explicitly (that's error returns,
std::expect, railway programming, etc.). Sometimes it is best to ensure
failure is not possible within the scope of the software, so that no
failure handling is needed (or nothing beyond abort(), kernel panic, etc.)

The only thing you can be sure about with failure handling is that
anyone who says they know the perfect answer, or that their preferred
method is always far better than others, is wrong.

> Avoiding exceptions looks hard to me because the runtime can throw a
> lot of exceptions, mostly bad_alloc()s or system_error()s.
>

Any code that sees a "bad_alloc" exception is already borked. It is not
failing because of the exception, it is failing because of the bad
programming.

Am 26.11.2023 um 16:28 schrieb David Brown:

> No, exceptions do not make things easier - they make them /different/.

Without exceptions you'd have to deal with return codes at each call
level; this *is* much more work.

> Sometimes it might be helpful to move failure handling to a different
> part of the code, sometimes it makes things harder.

In C++ exceptions are mostly used for resource collapse situations, i.e.
out of memory errors, network errors of filesystem failures. With that
exceptions are the most convenient way to handle that. These types of
errors are handled in most cases.

> Any code that sees a "bad_alloc" exception is already borked.

With exceptions you can handle such situations in a clean way with
a small effort.

> It is not failing because of the exception, it is failing because
> of the bad programming.

bad_alloc doesn't depend on the programming but rather how much memory
you have. You might ignore bad_alloc for small allocations since they're
unlikely to happen, but not for large allocations.
I don't understand your attitude while programming with C++ because the
runtime uses exceptions so much.

On 26/11/2023 18:51, Bonita Montero wrote:
> Am 26.11.2023 um 16:28 schrieb David Brown:
>
>> No, exceptions do not make things easier - they make them /different/.
>
> Without exceptions you'd have to deal with return codes at each call
> level; this *is* much more work.

As I said, anyone who claims their preference is always right, is wrong.

>
>> Sometimes it might be helpful to move failure handling to a different
>> part of the code, sometimes it makes things harder.
>
> In C++ exceptions are mostly used for resource collapse situations, i.e.
> out of memory errors, network errors of filesystem failures.

These are completely different situations. /Sometimes/ exceptions are a
convenient way to handle network or filesystem issues. They are never a
good way of handling out of memory errors, because out of memory errors
are caused by failures of the code, not external causes.

> With that
> exceptions are the most convenient way to handle that. These types of
> errors are handled in most cases.
>

Back here in the real world, most exceptions are /not/ handled -
programmers implementing the lower level functions think that exceptions
are someone else's problem and pass the buck up the line. Programmers
implementing the higher level parts don't know that the lower level
parts might through an exception - they assume functions do what they
claim to do.

Used properly, exceptions can be helpful in some situations.
Unfortunately they are rarely used properly.

>> Any code that sees a "bad_alloc" exception is already borked.
>
> With exceptions you can handle such situations in a clean way with
> a small effort.
>

No, you can't. You cannot magically make more memory appear, nor
magically fix the crappy code that caused a memory error in the first
place. You are blindly buying into the myth.

>> It is not failing because of the exception, it is failing because
>> of the bad programming.
>
> bad_alloc doesn't depend on the programming but rather how much memory
> you have. You might ignore bad_alloc for small allocations since they're
> unlikely to happen, but not for large allocations.

If you are trying to make an allocation that is too big for the system,
you are doing things wrong. Throwing an exception does not help,
because catching the exception cannot help.

> I don't understand your attitude while programming with C++ because the
> runtime uses exceptions so much.
>

The C++ code I use never throws exceptions. I never have them enabled.
I don't miss them.

(I don't use C++ for the kinds of uses where exceptions can be helpful.)

On 11/26/2023 11:27 AM, David Brown wrote:
> On 26/11/2023 18:51, Bonita Montero wrote:
>> Am 26.11.2023 um 16:28 schrieb David Brown:
>>
>>> No, exceptions do not make things easier - they make them /different/.
>>
>> Without exceptions you'd have to deal with return codes at each call
>> level; this *is* much more work.
>
> As I said, anyone who claims their preference is always right, is wrong.
>
>>
>>> Sometimes it might be helpful to move failure handling to a different
>>> part of the code, sometimes it makes things harder.
>>
>> In C++ exceptions are mostly used for resource collapse situations, i.e.
>> out of memory errors, network errors of filesystem failures.
>
> These are completely different situations.  /Sometimes/ exceptions are a
> convenient way to handle network or filesystem issues.  They are never a
> good way of handling out of memory errors, because out of memory errors
> are caused by failures of the code, not external causes.

Yup. One time I was experimenting with ways to allow a proxy server I
was coding up to die before exhausting non-paged memory by artificially
limiting the memory. This limit was used to make it go into a panic mode
even though it has exhausted all of the non-paged memory. It just got
too close. Iiic, it worked fairly well.

A panic mode would make the server drop all "stale", timedout, ect,
connections. It would also try to reclaim as much memory and resources
as it could, without cancelling currently active and working connections...

Basically, where you say:
________
They are never a good way of handling out of memory errors
________

Is true.

>
>> With that
>> exceptions are the most convenient way to handle that. These types of
>> errors are handled in most cases.
>>
>
> Back here in the real world, most exceptions are /not/ handled -
> programmers implementing the lower level functions think that exceptions
> are someone else's problem and pass the buck up the line.  Programmers
> implementing the higher level parts don't know that the lower level
> parts might through an exception - they assume functions do what they
> claim to do.
>
> Used properly, exceptions can be helpful in some situations.
> Unfortunately they are rarely used properly.
>
>>> Any code that sees a "bad_alloc" exception is already borked.
>>
>> With exceptions you can handle such situations in a clean way with
>> a small effort.
>>
>
> No, you can't.  You cannot magically make more memory appear, nor
> magically fix the crappy code that caused a memory error in the first
> place.  You are blindly buying into the myth.
>
>>> It is not failing because of the exception, it is failing because
>>> of the bad programming.
>>
>> bad_alloc doesn't depend on the programming but rather how much memory
>> you have. You might ignore bad_alloc for small allocations since they're
>> unlikely to happen, but not for large allocations.
>
> If you are trying to make an allocation that is too big for the system,
> you are doing things wrong.  Throwing an exception does not help,
> because catching the exception cannot help.
>
>> I don't understand your attitude while programming with C++ because the
>> runtime uses exceptions so much.
>>
>
> The C++ code I use never throws exceptions.  I never have them enabled.
> I don't miss them.
>
> (I don't use C++ for the kinds of uses where exceptions can be helpful.)
>
>
>
>

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 26.11.2023 um 13:54 schrieb David Brown:
>
>> Once you stop thinking that code can fail, and write code that doesn't
>> fail, it all becomes much easier, and RAII is just another useful tool.
>> (And you can compile with exceptions fully disabled.)
>
>With exceptions and RAII failures are also very easy to handle because
>you handle them only at a few places and not where they happen or in
>the call levels between.
>Avoiding exceptions looks hard to me because the runtime can throw a
>lot of exceptions, mostly bad_alloc()s or system_error()s.

Given that C++ predates the standard C++ library, it's clearly
possible to write C++ code without a runtime that throws a lot
of exceptions. (exceptions didn't show up until C++3.0).

It is also possible to build a runtime that never throws
exceptions.

On 11/26/2023 2:38 PM, Chris M. Thomasson wrote:
> On 11/26/2023 11:27 AM, David Brown wrote:
>> On 26/11/2023 18:51, Bonita Montero wrote:
>>> Am 26.11.2023 um 16:28 schrieb David Brown:
>>>
>>>> No, exceptions do not make things easier - they make them /different/.
>>>
>>> Without exceptions you'd have to deal with return codes at each call
>>> level; this *is* much more work.
>>
>> As I said, anyone who claims their preference is always right, is wrong.
>>
>>>
>>>> Sometimes it might be helpful to move failure handling to a
>>>> different part of the code, sometimes it makes things harder.
>>>
>>> In C++ exceptions are mostly used for resource collapse situations, i.e.
>>> out of memory errors, network errors of filesystem failures.
>>
>> These are completely different situations.  /Sometimes/ exceptions are
>> a convenient way to handle network or filesystem issues.  They are
>> never a good way of handling out of memory errors, because out of
>> memory errors are caused by failures of the code, not external causes.
>
> Yup. One time I was experimenting with ways to allow a proxy server I
> was coding up to die before exhausting non-paged memory by artificially
> limiting the memory. This limit was used to make it go into a panic mode
> even though it has exhausted all of the non-paged memory. It just got
> too close. Iiic, it worked fairly well.
>
> A panic mode would make the server drop all "stale", timedout, ect,
> connections. It would also try to reclaim as much memory and resources
> as it could, without cancelling currently active and working connections...
>
> Basically, where you say:
> ________
> They are never a good way of handling out of memory errors
> ________
>
> Is true.
>
>
>
>>
>>> With that
>>> exceptions are the most convenient way to handle that. These types of
>>> errors are handled in most cases.
>>>
>>
>> Back here in the real world, most exceptions are /not/ handled -
>> programmers implementing the lower level functions think that
>> exceptions are someone else's problem and pass the buck up the line.
>> Programmers implementing the higher level parts don't know that the
>> lower level parts might through an exception - they assume functions
>> do what they claim to do.
>>
>> Used properly, exceptions can be helpful in some situations.
>> Unfortunately they are rarely used properly.
>>
>>>> Any code that sees a "bad_alloc" exception is already borked.
>>>
>>> With exceptions you can handle such situations in a clean way with
>>> a small effort.
>>>
>>
>> No, you can't.  You cannot magically make more memory appear, nor
>> magically fix the crappy code that caused a memory error in the first
>> place.  You are blindly buying into the myth.
>>
>>>> It is not failing because of the exception, it is failing because
>>>> of the bad programming.
>>>
>>> bad_alloc doesn't depend on the programming but rather how much memory
>>> you have. You might ignore bad_alloc for small allocations since they're
>>> unlikely to happen, but not for large allocations.
>>
>> If you are trying to make an allocation that is too big for the
>> system, you are doing things wrong.  Throwing an exception does not
>> help, because catching the exception cannot help.
>>
>>> I don't understand your attitude while programming with C++ because the
>>> runtime uses exceptions so much.
>>>
>>
>> The C++ code I use never throws exceptions.  I never have them
>> enabled. I don't miss them.
>>
>> (I don't use C++ for the kinds of uses where exceptions can be helpful.)
>>
>>
>>
>>
>

Man, I have not thought about this in a while. Wrt my proxy server, I
made it express itself where I could reap data on a so-called max and
min basis. The max would mean it used all non-paged memory and damn near
blue screened, wrt WinNT. The min means that it got close to gravely
hurting the system, but things still work...

Max: we can obtain this by allow the proxy server to crash itself, and
we are real time taking stats all the way down. We then take a look at
the data that caused it to crash...

Min: Divide certain parts of the data obtained from Max by say, two,
just for starters. So, for instance, we can say this many connections
crashed it wrt Max. Lets try to limit it to half of those. Then we run
the proxy server again with that artificial limit that denys new
connection attempts, and it does not exhaust all of the non-paged memory
at all. Then we try again by increacing the Min to to Max. Keep in mind
that if Min=Max, it will use all of the non-paged pool, and bring the
system to a fucking crawl...

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.

Huh? This does not make sense to me at all. Have you ever used GQCS or
GQCSEX at all? Humm...

>
>> So your hack can break at any time? ...
>
> It would be nice if MS would document since when this works.

LOL! You are a character.

>
>> 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.
>

Huh?

Am 26.11.2023 um 20:27 schrieb David Brown:

> They are never a good way of handling out of memory errors, because
> out of memory errors are caused by failures of the code, not external
> causes.

These errors can happen depending on the type of application and
bad_alloc()s are a clean way to handle that. All other ways to
handle that like error codes are less convenient.

> Back here in the real world, most exceptions are /not/ handled - ...

You're talking about your applications and you think all peopl
do it like you do.

> No, you can't.  You cannot magically make more memory appear, ...

No one claims that for exceptions, but you can stop an operation
and recover from that with RAII and exceptions in a clean way.

> If you are trying to make an allocation that is too big for the system,
> you are doing things wrong. ...

This usually doesn't depend on the application but on the input
of a user.

> The C++ code I use never throws exceptions. ...

Then you must have dropped most parts of the standardy library.

Am 27.11.2023 um 00:45 schrieb Chris M. Thomasson:
> 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.
>
> Huh? This does not make sense to me at all. Have you ever used GQCS or
> GQCSEX at all? Humm...

Idiot ...

>
>
>>
>>> So your hack can break at any time? ...
>>
>> It would be nice if MS would document since when this works.
>
> LOL! You are a character.
>
>>
>>> 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.
>>
>
> Huh?

On 11/26/2023 8:24 PM, Bonita Montero wrote:
> Am 27.11.2023 um 00:45 schrieb Chris M. Thomasson:
>> 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.
>>
>> Huh? This does not make sense to me at all. Have you ever used GQCS or
>> GQCSEX at all? Humm...
>
> Idiot ...

You are the one that wants to pass a IOCP handle to WFMO, idoit!

I still don't think you know how GQCS and/or GQCSEX works.

>
>>
>>
>>>
>>>> So your hack can break at any time? ...
>>>
>>> It would be nice if MS would document since when this works.
>>
>> LOL! You are a character.
>>
>>>
>>>> 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.
>>>
>>
>> Huh?
>

Am 27.11.2023 um 07:22 schrieb Chris M. Thomasson:
> On 11/26/2023 8:24 PM, Bonita Montero wrote:
>> Am 27.11.2023 um 00:45 schrieb Chris M. Thomasson:
>>> 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.
>>>
>>> Huh? This does not make sense to me at all. Have you ever used GQCS
>>> or GQCSEX at all? Humm...
>>
>> Idiot ...
>
> You are the one that wants to pass a IOCP handle to WFMO, idoit!

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.

> I still don't think you know how GQCS and/or GQCSEX works.

You don't understand what I write.

On 11/26/2023 11:57 PM, Bonita Montero wrote:
> Am 27.11.2023 um 07:22 schrieb Chris M. Thomasson:
>> On 11/26/2023 8:24 PM, Bonita Montero wrote:
>>> Am 27.11.2023 um 00:45 schrieb Chris M. Thomasson:
>>>> 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.
>>>>
>>>> Huh? This does not make sense to me at all. Have you ever used GQCS
>>>> or GQCSEX at all? Humm...
>>>
>>> Idiot ...
>>
>> You are the one that wants to pass a IOCP handle to WFMO, idoit!
>
> 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. Iirc, WFMO does not have to be atomic in the way it waits
on the HANDLE's. It can be broken down into multiple WFSO's.

>> I still don't think you know how GQCS and/or GQCSEX works.
>
> You don't understand what I write.

Whatever you say. Take note of:

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.
________________

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.

> 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 27/11/2023 05:23, Bonita Montero wrote:
> Am 26.11.2023 um 20:27 schrieb David Brown:
>
>> They are never a good way of handling out of memory errors, because
>> out of memory errors  are caused by failures of the code, not external
>> causes.
>
> These errors can happen depending on the type of application and
> bad_alloc()s are a clean way to handle that. All other ways to
> handle that like error codes are less convenient.

Out of memory failures are /never/ clean. A program that tries to get
more memory than is available, using standard allocators, is broken.

I am not saying that the alternative to bad_alloc exceptions is error
codes for memory failures - I am saying that the alternative is not
having memory allocation failures during normal operations.

>
>> Back here in the real world, most exceptions are /not/ handled - ...
>
> You're talking about your applications and you think all peopl
> do it like you do.

No, I am talking about reality. /I/ don't use exceptions in C++. They
are not enabled in my builds. How exceptions are handled is a
meaningless question for my own code.

It is extremely difficult to write truly exception-safe code, where the
code will work correctly in the face of unexpected exceptions happening
from pretty much any function call. It is possible for some kinds of
code, when developers have enough knowledge and experience, and are able
to spend enough time and effort on it. But that is a small minority.

Oh, and the exception handling is almost always untested - or at least,
far from comprehensively tested.

That does not mean that exceptions are always bad - they can be a useful
way to handle some issues. And it does not mean that error codes or
other solutions are always good - most error-handling code of any sort
is untested. It means they are a tool that should be understood and
used when appropriate, but they should not be over-estimated as you do.

(If C++ exceptions were as perfect as you imagine, why do you think
there is such a strong pressure in the C++ standards and development
groups to move towards things like "zero-overhead deterministic
exceptions" ? Why do we have std::expected<> in C++23?)

>
>> No, you can't.  You cannot magically make more memory appear, ...
>
> No one claims that for exceptions, but you can stop an operation
> and recover from that with RAII and exceptions in a clean way.
>

Keep telling yourself that. You won't persuade others, but maybe you'll
feel happier.

>> If you are trying to make an allocation that is too big for the
>> system, you are doing things wrong. ...
>
> This usually doesn't depend on the application but on the input
> of a user.
>

An application that does not check the input from the user is doing
things wrong.

>> The C++ code I use never throws exceptions. ...
>
> Then you must have dropped most parts of the standardy library.
>

Of course I have. It is useless for the work I do.

That doesn't mean it is useless for other people and other types of
coding, of course.

Actually, most of the standard library uses exceptions only very rarely,
and in many of these cases the only possible exception is for memory
allocation failure - which should only occur if your program is badly
borked.

Am 27.11.2023 um 10:38 schrieb David Brown:

> Out of memory failures are /never/ clean.  A program that tries to get
> more memory than is available, using standard allocators, is broken.

No, usually that depends on the input and this is a valid situation for
most applications.

> I am not saying that the alternative to bad_alloc exceptions is error
> codes for memory failures - I am saying that the alternative is not
> having memory allocation failures during normal operations.

That may be true for a lot of applications, but it doesn't hurt to
handle that and for applications which may require a lot of memory
- depending on the input - this is absolutely necessary.

> No, I am talking about reality.  /I/ don't use exceptions in C++.
> They are not enabled in my builds.  How exceptions are handled is
> a meaningless question for my own code.

The standard library would simply terminate if exceptions support is
disabled because there is no unwinding code for the caller, that's
un-clean.

> It is extremely difficult to write truly exception-safe code, ...

Absolutely not if you use RAII consequently.

> An application that does not check the input from the user is doing
> things wrong.

The application itself can't decide that, it's part of the memory
management which says if there's enough memory or not, partitially
depending on the kernel, partitially depending on the user-space
pooling. The application below that can't do that.

> Of course I have.  It is useless for the work I do.

And you think it's useless for everyone by saying that handling
bad_alloc doesn't usually make sense.

On 27/11/2023 10:55, Bonita Montero wrote:
> Am 27.11.2023 um 10:38 schrieb David Brown:

>> Of course I have.  It is useless for the work I do.
>
> And you think it's useless for everyone by saying that handling
> bad_alloc doesn't usually make sense.
>

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.

The way you move the goalposts around, fail to read posts, and fail to
address questions, makes it clear that you prefer cultish believe to
learning and thinking. And since you don't want to learn or think,
there is little point in discussing with you.