Saturday, September 30, 2023

Digest for comp.programming.threads@googlegroups.com - 1 update in 1 topic

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:

Wednesday, September 27, 2023

Digest for comp.lang.c++@googlegroups.com - 8 updates in 1 topic

scott@slp53.sl.home (Scott Lurndal): Sep 27 10:37PM


>I need to examine the kernel for nt4 again:
 
>https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos
 
Why? It's a quarter century old. Did it even support threads?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 27 03:49PM -0700

On 9/27/2023 3:37 PM, Scott Lurndal wrote:
 
>> I need to examine the kernel for nt4 again:
 
>> https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos
 
> Why? It's a quarter century old. Did it even support threads?
 
NT 4? Yup, it supported threads.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 27 03:56PM -0700

On 9/27/2023 3:25 PM, Michael S wrote:
>> I cannot remember kernel keyed events were implemented in win7, I am
>> pretty sure they were. Have you ever messed around with those before?
 
> I have no idea what the phrase "kernel keyed events" means.
 
There is a sync object in windows called a keyed event, however I think
its only for the kernel. Iirc, I learned about it in a sysinternals
magazine. Forgot the issue number. It is a special type of Windows Event
object.
 
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 27 03:57PM -0700

On 9/27/2023 3:27 PM, Kaz Kylheku wrote:
>> Ws2016, so I expect the same behavior with very high certainty.
 
> Could this in any way be related to Microsoft evidently obtaining a patent on
> futexes in 2014?
 
NO SHIT!!! ;^o wow.!
Michael S <already5chosen@yahoo.com>: Sep 27 03:59PM -0700

On Thursday, September 28, 2023 at 1:37:48 AM UTC+3, Scott Lurndal wrote:
 
> >I need to examine the kernel for nt4 again:
 
> >https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos
> Why? It's a quarter century old. Did it even support threads?
 
Windows Nt supports threads since its very first version, non-intuitively
named 3.1. I.e. 30 years.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 27 04:06PM -0700

On 9/27/2023 3:59 PM, Michael S wrote:
 
>>> https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos
>> Why? It's a quarter century old. Did it even support threads?
 
> Windows Nt supports threads since its very first version,
 
Yup. You are correct. Windows NT 4 even had IOCP.
 
Michael S <already5chosen@yahoo.com>: Sep 27 04:10PM -0700

On Thursday, September 28, 2023 at 2:06:33 AM UTC+3, Chris M. Thomasson wrote:
> >> Why? It's a quarter century old. Did it even support threads?
 
> > Windows Nt supports threads since its very first version,
> Yup. You are correct. Windows NT 4 even had IOCP.
 
Didn't IOCP come earlier? Nt 3.5?
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 27 04:15PM -0700

On 9/27/2023 4:10 PM, Michael S wrote:
 
>>> Windows Nt supports threads since its very first version,
>> Yup. You are correct. Windows NT 4 even had IOCP.
 
> Didn't IOCP come earlier? Nt 3.5?
 
Good question. I cannot remember right now! I used it a lot in NT 4.
Shit, your question kind of got me here. I cannot remember right now.
Anyway, thanks for the brain sparks, Michael!
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Tuesday, September 26, 2023

Digest for comp.lang.c++@googlegroups.com - 10 updates in 2 topics

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 02:11PM -0700

On 9/26/2023 1:58 PM, Michael S wrote:
>> fun because its so weak.
 
> We discussed it already. I don't think that SPARCv9 RMO hardware
> ever existed and you failed to convince me otherwise.
 
[...]
 
heck, have you ever had to use a DEC Alpha that was so weak it did not
even honor data dependent loads? This is interesting wrt RCU... ;^)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 02:17PM -0700

On 9/26/2023 1:58 PM, Michael S wrote:
> ever existed and you failed to convince me otherwise.
 
> As to weakness, I don't think that by specification it is weaker than IPF,
> may be not even weaker than POWER. Certainly stronger than Alpha.
 
The damn DEC Alpha did not even honor data-dependent loads, that is very
weak. It's so weak it has to use membars to implement RCU.
 
Sparc in RMO mode requires explicit MEMBAR for acquire and release. IN
TSO mode it had implicit acquire and release wrt loads and stores much
like x86.
Michael Fisher <michaelsfishers61@gmail.com>: Sep 26 02:40PM -0700

Buy your driver's license,Passport, Visa, EITLS exams, Fake bank notes whatsapp: +1(541)782-8482
 
we supply perfectly reproduced counterfeit money with holograms and all security features available.
Indistinguishable to the eye and to touch.contact today
whatsapp : +1(541)782-8482
Email: Cliffbudman237@gmail.com
https://procounterfeitshop.company.com/
 
Why would you buy from us?
Our banknotes contain the following security features that make it to be genius and we have the best grade counterfeit in the world both Euro and Dollar and any bills of your choice you want. Security features of our bank notes are AAA grade with the following quality : Intaglio printing Watermarks Security thread See-through register Special foil/special foil elements Iridescent stripe / shifting colors. -Holograms and Holographic Strips -Micro-Lettering -Metallic Ink and Thread -Watermarks -IR Detection -Ultra-violet features -See through Features -Different serial numberwe offer both national and international deliveries. All of our deliveries are safe, fast and discreet.
All customer delivery information is eliminated after delivery to ensure a fair deal .
We supply only original high-quality BANKNOTES to all countries worldwide.
We print and sell perfect Grade A BANKNOTES of over 52 currencies. Our money is perfectly reproduced with all security features available and we assure you everything is safe and indistinguishable to the human eye and touch (REAL MONEY LOOK AND FEEL).
EUR - Euro
USD - US Dollar
GBP - British Pound
AUD - Australian Dollar
CAD - Canadian
and many more
Delivery usually takes 2-5 days
-Free shipping
-THE bills/notes bypass everything, counterfeit pens and machines.
-I have the best HOLOGRAMS AND DUPLICATING MACHINES
-UV: YES
-All security features available
contact today
whatsapp : whatsapp : +1(541)782-8482
Email: Cliffbudman237@gmail.com
https://procounterfeitshop.company.com/
 
 
WHERE CAN I USE THESE BANKNOTE?
 
MC DONALD'S , SHOPS , RESTAURANTS , SUPERMARKETS , PETROL SHOPS , GAME HALL , ATM, BANKS,SHOPPING MALLS , GAME AND ATTRACTION PARKS , ELECTRONIC SHOPS , TAXI , METRO AND TRAIN STATION , USED TO PAY BUS AND ANY TRANSPORTATION

Tags:
counterfeit cash, counterfeiting
High Quality Undetectable Counterfeit Banknotes For Sale
HIGH QUALITY UNDETECTABLE COUNTERFEIT BANKNOTES FOR SALE
BUY SUPER HIGH QUALITY FAKE MONEY ONLINE GBP, DOLLAR, EUROS
BUY 100% UNDETECTABLE COUNTERFEIT MONEY £,$,€
BEST COUNTERFEIT MONEY ONLINE, DOLLARS, GBP, EURO NOTES AVAILABLE
BUY TOP GRADE COUNTERFEIT MONEY ONLINE, DOLLARS, GBP, EURO NOTES AVAILABLE.
TOP QUALITY COUNTERFEIT MONEY FOR SALE. DOLLAR, POUNDS, EUROS AND OTHER CURRENCIES AVAILABLE
Counterfeit money for sale
money, banknotes, fake money, prop money,
EUROS,DOLLARS AND POUNDS AND NOVELTY DOCUMENTS LIKE PASSPORTS,ID CARDS,GREEN CARDS AND DRIVERS LICENSE
counterfeit money for sale, buy fake money online, fake dollars, fake pounds, fake euro, buy money online, fake money for
 
sale. Buy Fake Dollars, Buy Fake British Pounds, Buy Fake Euro, Money, where can i buy counterfeit money?.
 
 
BUY QUALITY COUNTERFEIT MONEY WHATSAPP ME AT +1(541)782-8482 EUROS,DOLLARS AND POUNDS .AND S.S.D CHEMICALS.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 03:07PM -0700

On 9/25/2023 11:08 AM, Kaz Kylheku wrote:
 
>> And implementation that throws in this situation isn't bad for me.
 
> An implementation that throws in mutex locks that aren't process-shared
> robust mutexes or anything of that sort is a ... sick joke.
 
Big time.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 03:28PM -0700

On 9/21/2023 11:42 AM, Kaz Kylheku wrote:
 
> When the scheduler determines there is truly nothing to do then it is
> legitimate to dispatch an idle task which suspends the processor until
> an external event.
 
Wrt adaptive backoff, did you ever read the following paper?
 
https://dl.acm.org/doi/10.1145/2686884
 
Iirc, David was an author on the paper I am having trouble finding wrt QPI.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 03:31PM -0700

On 9/21/2023 11:42 AM, Kaz Kylheku wrote:
 
> When the scheduler determines there is truly nothing to do then it is
> legitimate to dispatch an idle task which suspends the processor until
> an external event.
 
Damn it! I cannot find that paper wrt QPI or the quick path interconnect
wrt Intel, and how to abuse it for even a userspace RCU.
Richard Damon <Richard@Damon-Family.org>: Sep 26 06:38PM -0400

On 9/26/23 8:36 AM, Bonita Montero wrote:
> create an aribtrary number of that on any operating system. Yieling
> is inefficient and I also mentioned why spin-locking is totally
> inacceptable.
 
Only if you do it wrong, like you are doing.
 
You THINK yielding is inefficient, but it really isn't.
 
IT only gives time to other threads that actually need it, so the
processor is kept doing useful work.
 
You also don't seem to understand how Schedulers ACTUALLY WORK.
 
Just shows your ignorance.
Richard Damon <Richard@Damon-Family.org>: Sep 26 06:40PM -0400

On 9/26/23 11:33 AM, Bonita Montero wrote:
 
> The userspace code must tell the kernel what it its waiting for.
> Mutexes are always a combination of an atomic for the fast path
> and a binary semapohre for the slow path.
 
Sorry to tell you that you are just wrong.
 
Please point to the code in the kernal that actually does this.
 
If you can't, your just admitting that you have been lying about knowing
how it works.
Kaz Kylheku <864-117-4973@kylheku.com>: Sep 26 11:16PM

>> and resume(). There was no kernel object to allocate.
 
> Maybe, but the C++ standard shoudn't mandate that. If you implement
> a mutex yourself under Windows you'd need a kernel event or semaphore.
 
Only if you had no imagination, research abilility, or skills for
porting ideas from elsewhere to Windows.
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Michael Fisher <michaelsfishers61@gmail.com>: Sep 26 02:39PM -0700

Buy your driver's license,Passport, Visa, EITLS exams, Fake bank notes whatsapp: +1(541)782-8482
 
we supply perfectly reproduced counterfeit money with holograms and all security features available.
Indistinguishable to the eye and to touch.contact today
whatsapp : +1(541)782-8482
Email: Cliffbudman237@gmail.com
https://procounterfeitshop.company.com/
 
Why would you buy from us?
Our banknotes contain the following security features that make it to be genius and we have the best grade counterfeit in the world both Euro and Dollar and any bills of your choice you want. Security features of our bank notes are AAA grade with the following quality : Intaglio printing Watermarks Security thread See-through register Special foil/special foil elements Iridescent stripe / shifting colors. -Holograms and Holographic Strips -Micro-Lettering -Metallic Ink and Thread -Watermarks -IR Detection -Ultra-violet features -See through Features -Different serial numberwe offer both national and international deliveries. All of our deliveries are safe, fast and discreet.
All customer delivery information is eliminated after delivery to ensure a fair deal .
We supply only original high-quality BANKNOTES to all countries worldwide.
We print and sell perfect Grade A BANKNOTES of over 52 currencies. Our money is perfectly reproduced with all security features available and we assure you everything is safe and indistinguishable to the human eye and touch (REAL MONEY LOOK AND FEEL).
EUR - Euro
USD - US Dollar
GBP - British Pound
AUD - Australian Dollar
CAD - Canadian
and many more
Delivery usually takes 2-5 days
-Free shipping
-THE bills/notes bypass everything, counterfeit pens and machines.
-I have the best HOLOGRAMS AND DUPLICATING MACHINES
-UV: YES
-All security features available
contact today
whatsapp : whatsapp : +1(541)782-8482
Email: Cliffbudman237@gmail.com
https://procounterfeitshop.company.com/
 
 
WHERE CAN I USE THESE BANKNOTE?
 
MC DONALD'S , SHOPS , RESTAURANTS , SUPERMARKETS , PETROL SHOPS , GAME HALL , ATM, BANKS,SHOPPING MALLS , GAME AND ATTRACTION PARKS , ELECTRONIC SHOPS , TAXI , METRO AND TRAIN STATION , USED TO PAY BUS AND ANY TRANSPORTATION

Tags:
counterfeit cash, counterfeiting
High Quality Undetectable Counterfeit Banknotes For Sale
HIGH QUALITY UNDETECTABLE COUNTERFEIT BANKNOTES FOR SALE
BUY SUPER HIGH QUALITY FAKE MONEY ONLINE GBP, DOLLAR, EUROS
BUY 100% UNDETECTABLE COUNTERFEIT MONEY £,$,€
BEST COUNTERFEIT MONEY ONLINE, DOLLARS, GBP, EURO NOTES AVAILABLE
BUY TOP GRADE COUNTERFEIT MONEY ONLINE, DOLLARS, GBP, EURO NOTES AVAILABLE.
TOP QUALITY COUNTERFEIT MONEY FOR SALE. DOLLAR, POUNDS, EUROS AND OTHER CURRENCIES AVAILABLE
Counterfeit money for sale
money, banknotes, fake money, prop money,
EUROS,DOLLARS AND POUNDS AND NOVELTY DOCUMENTS LIKE PASSPORTS,ID CARDS,GREEN CARDS AND DRIVERS LICENSE
counterfeit money for sale, buy fake money online, fake dollars, fake pounds, fake euro, buy money online, fake money for
 
sale. Buy Fake Dollars, Buy Fake British Pounds, Buy Fake Euro, Money, where can i buy counterfeit money?.
 
 
BUY QUALITY COUNTERFEIT MONEY WHATSAPP ME AT +1(541)782-8482 EUROS,DOLLARS AND POUNDS .AND S.S.D CHEMICALS.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Digest for comp.lang.c++@googlegroups.com - 25 updates in 1 topic

scott@slp53.sl.home (Scott Lurndal): Sep 26 03:25PM

>> "defective" method can be used.
 
>Pthread mutexes can be initialized statically, but then you have the
>same kind of delayed inititialization - which may fail.
 
No, there is no delayed initialization with pthread mutexes.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 26 05:30PM +0200

Am 26.09.2023 um 17:25 schrieb Scott Lurndal:
 
> No, there is no delayed initialization with pthread mutexes.
 
There must be since you can't create a semaphore by pure assignment.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 26 05:31PM +0200

Am 26.09.2023 um 17:23 schrieb Scott Lurndal:
 
> No, it is not.
 
What else ?
Bonita Montero <Bonita.Montero@gmail.com>: Sep 26 05:33PM +0200

Am 26.09.2023 um 17:24 schrieb Scott Lurndal:
 
> a non-runnable queue in the dispatcher until a call to 'unlock'
> determines that there is a waiter and tells the kernel to
> awaken it.
 
The userspace code must tell the kernel what it its waiting for.
Mutexes are always a combination of an atomic for the fast path
and a binary semapohre for the slow path.
Michael S <already5chosen@yahoo.com>: Sep 26 08:52AM -0700

On Tuesday, September 26, 2023 at 6:31:13 PM UTC+3, Bonita Montero wrote:
> Am 26.09.2023 um 17:25 schrieb Scott Lurndal:
 
> > No, there is no delayed initialization with pthread mutexes.
> There must be since you can't create a semaphore by pure assignment.
 
I don't know how it works for pthread mutexes on any possible OS
that supports pthreads.
But I do know that Windows SRW Lock can be initialized statically.
Also I do know that it does not have to be destroyed. As long
as no threads are locked on it, it can be simply abandoned.
 
https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initializesrwlock
"An unlocked SRW lock with no waiting threads is in its initial state and can be copied,
moved, and forgotten without being explicitly destroyed."
 
Which is a very strong hint that there is no hidden kernel object per
lock behind the scene. And very likely no hidden kernel object per any
fixed number of SRW locks.
Michael S <already5chosen@yahoo.com>: Sep 26 09:05AM -0700

On Tuesday, September 26, 2023 at 8:53:13 AM UTC+3, Chris M. Thomasson wrote:
> performance for certain workloads. Actually, there is a way to use it to
> get a RCU in userspace and/or hazard pointers without any explicit
> #StoreLoad membars.
 
I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude
slower than #StoreLoad membar. I could be wrong, of course, the function
is close to undocumented.
 
Bonita Montero <Bonita.Montero@gmail.com>: Sep 26 06:08PM +0200

Am 26.09.2023 um 17:52 schrieb Michael S:
 
> I don't know how it works for pthread mutexes ...
 
LOL
 
> But I do know that Windows SRW Lock can be initialized statically.
 
Maybe, but this is also possible with delayed initialization.
Kaz Kylheku <864-117-4973@kylheku.com>: Sep 26 04:46PM

>> as documented.
 
> I meant to say that this is something to be expected on any platform,
> not that it actually happens.
 
If you're betting your business on writing some multithreading
application for a platform, you should know what actually happens on
the platform.
 
You probably don't choose a platform where mutexes require resources
that are only allocated on lock contention, and which can then blow up.
 
If you do choose that platform, you have some plan. You identify under
which conditions such a problem happens. Perhaps the system can be
configured to minimize the risk. Or perhasps there are warning signs,
like low memory, so that evasive action can be taken: clean shutdown and
restart.
 
Memory overcommit is enabled on most GNU/Linux system installations.
This means that memory allocations can fail not when you allocate
the memory (e.g. mmap() returning MAP_FAILED or malloc returning null)
but when you try to access the memory.
 
You don't necessarily combat this in the application code. Ways to deal
with it range from reducing or disabling overcommit, to just having
enough swap space for a soft landing: evasive action taken when the
system shows signs of thrashing.
 
Most programs at most check for up-front allocator failure; most are not
prepared to handle an access violation upon using the result of a
successful-looking allocation.
 
Assuming you have some mutex type which is "overcommitted" similarly,
similar reasoning applies.
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 26 06:54PM +0200

Am 26.09.2023 um 18:46 schrieb Kaz Kylheku:
 
> You probably don't choose a platform where mutexes require resources
> that are only allocated on lock contention, and which can then blow up.
 
Contention is always possible and always expensive.
 
> This means that memory allocations can fail not when you allocate
> the memory (e.g. mmap() returning MAP_FAILED or malloc returning null)
> but when you try to access the memory.
 
Memory overcommit partitially bases on swappable memory. Seamphores are
in non-pageable memory inside the kernel. But I accept what you mean: if
you accept that an application can suddenly terminate because of the OOM
killer you also might accept that it would be terminated because a sin-
gle kernel semaphore coudn't be created. That may be acceptable for most
users but if there's an error code from the kernel this still should be
forwarded through your runtime for those who coudln't accept that.
Michael S <already5chosen@yahoo.com>: Sep 26 10:00AM -0700

On Tuesday, September 26, 2023 at 7:08:43 PM UTC+3, Bonita Montero wrote:
 
> LOL
> > But I do know that Windows SRW Lock can be initialized statically.
> Maybe, but this is also possible with delayed initialization.
 
If you were reading my post up to the end you were understanding that
such possibility is extremely low.
Kaz Kylheku <864-117-4973@kylheku.com>: Sep 26 05:01PM

>> "defective" method can be used.
 
> Pthread mutexes can be initialized statically, but then you have the
> same kind of delayed inititialization - which may fail.
 
It has already been explained that none of the error codes given in
POSIX for the pthread_mutex_lock function have anything to do with
resource acquisition.
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Michael S <already5chosen@yahoo.com>: Sep 26 10:04AM -0700

On Tuesday, September 26, 2023 at 8:01:00 PM UTC+3, Michael S wrote:
> > Maybe, but this is also possible with delayed initialization.
> If you were reading my post up to the end you were understanding that
> such possibility is extremely low.
 
I meant to write 'extremely unlikely'.
Kaz Kylheku <864-117-4973@kylheku.com>: Sep 26 05:09PM

> Am 26.09.2023 um 17:25 schrieb Scott Lurndal:
 
>> No, there is no delayed initialization with pthread mutexes.
 
> There must be since you can't create a semaphore by pure assignment.
 
It has already been explained that there are multiple ways to implement
mutexes.
 
The approach which requires a kernel semaphore handle to be allocated
is a possibility. It would be difficult under POSIX because the
static initializer will not do that, and the lock operation is not
described as returning a resource-related error code.
 
In Linux, the original threads implementation in Glibc, based on
Xavier Leroy's LinuxThreads didn't use one semaphore per mutex.
It used POSIX signals to implement internal functions suspend()
and resume(). There was no kernel object to allocate.
 
The NPTL rewrite of the treading library was accompanied by futexes
in the kernel. Futexes also don't require allocation. Any memory
location in your virtual space can be used as a futex without any
resources being registered. Futexes were designed that way specifically
in order not to have mutex initialization fail on resource acquisition,
or waste time in the kernel, so that mutexes can be cheaply and safely.
 
Futexes use a fixed pool of wait queues which is allocated upfront. The
memory location is hashed to a wait queue, which it possibly shares with
unrelated futexes due to hash collisions.
 
There is no reason for any commercial, proprietary platform to do worse
than open source did twenty years ago, or for anyone to use it if it
sodes.
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
scott@slp53.sl.home (Scott Lurndal): Sep 26 05:13PM


>It has already been explained that none of the error codes given in
>POSIX for the pthread_mutex_lock function have anything to do with
>resource acquisition.
 
Although it is fair to point out that POSIX allows additional
implementation-defined error codes for POSIX interfaces, so long
as the listed conditions return the listed error codes.
 
That's not meant to imply that posix mutexes will ever fail, however.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 26 07:30PM +0200

Am 26.09.2023 um 19:00 schrieb Michael S:
 
> If you were reading my post up to the end you were understanding that
> such possibility is extremely low.
 
I think that's a common optimization since in many cases mutexes aren't
contended at all, thereby not needing any semaphore, or contended very
late.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 26 07:33PM +0200

Am 26.09.2023 um 19:09 schrieb Kaz Kylheku:
 
> Xavier Leroy's LinuxThreads didn't use one semaphore per mutex.
> It used POSIX signals to implement internal functions suspend()
> and resume(). There was no kernel object to allocate.
 
Maybe, but the C++ standard shoudn't mandate that. If you implement
a mutex yourself under Windows you'd need a kernel event or semaphore.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 12:58PM -0700

On 9/26/2023 9:05 AM, Michael S wrote:
 
> I would expect FlushProcessWriteBuffers() to be 2 orders of magnitude
> slower than #StoreLoad membar. I could be wrong, of course, the function
> is close to undocumented.
 
FlushProcessWriteBuffers() can be used to gain a quiescent state wrt
memory visibility for some exotic async algorithms, it is called in
certain places and is RARE. However, on the other hand, having to use a
#StoreLoad membar on the fast path is not good. Keep in mind that this
is meant to handle a store followed by a load to another location
scenario. We need to honor the #StoreLoad relationship for this type of
setup for these types of algorithms. For instance, hazard pointers
require a #StoreLoad, however there is a way to eliminate them using
some special magic wrt RCU...
 
My friend Joe Seigh created SMR+RCU to gain this. SMR is hazard
pointers. Now, keep in mind that these are very "specialized" algorithms
that try to make certain workloads MUCH faster and way more efficient.
They work for that.
 
Also, keep in mind that a normal mutex does not require #StoreLoad. Only
acquire and release:
 
acquire = #LoadStore | #LoadLoad
release = #LoadStore | #StoreStore
 
In SPARC parlance. For instance, an atomic store on x86 automatically
implies release. Btw, have you ever worked with SPARC in RMO mode? Its
fun because its so weak.
 
I still need to find that old paper called QPI, if I remember correctly.
It should still be out there. I will try to find it sometime today.
 
It think is was from Dice wrt a Java VM. David Dice? Damn I cannot
remember it right now. Sorry. ;^o
 
 
[...]
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 01:02PM -0700

On 9/26/2023 8:31 AM, Bonita Montero wrote:
> Am 26.09.2023 um 17:23 schrieb Scott Lurndal:
 
>> No, it is not.
 
> What else ?
 
Sigh.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 01:04PM -0700

On 9/26/2023 4:23 AM, Richard Damon wrote:
>> initialization can fail.
 
> Nope, if you do it right, a suitable synchronization object can be
> created without possibility of error.
 
Bonita needs to learn that there are ways to, do it right. For some damn
reason, it reminds me of the following crazy song from Daft Punk.
Actually, Daft Punk reminds me of Bonita for some strange reason... Robots?
 
https://youtu.be/LL-gyhZVvx0
 
Everybody will be dancing when we are doing it right...
 
;^)
 
 
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 01:06PM -0700

On 9/26/2023 5:37 AM, Bonita Montero wrote:
>> a bad implementation.
 
> The slow path always is backed by a binary semaphore of the kernel.
> You can't create an arbitrary number of that.
 
Barf! God damn it Bonita! I might have to try to refrain from reading
your posts. PUKE!
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 01:07PM -0700

On 9/26/2023 8:33 AM, Bonita Montero wrote:
 
> The userspace code must tell the kernel what it its waiting for.
> Mutexes are always a combination of an atomic for the fast path
> and a binary semapohre for the slow path.
 
Word salad that you do not even understand. Sorry buddy.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 01:21PM -0700

On 9/26/2023 10:13 AM, Scott Lurndal wrote:
> implementation-defined error codes for POSIX interfaces, so long
> as the listed conditions return the listed error codes.
 
> That's not meant to imply that posix mutexes will ever fail, however.
 
Good point. :^)
Michael S <already5chosen@yahoo.com>: Sep 26 01:58PM -0700

On Tuesday, September 26, 2023 at 10:59:06 PM UTC+3, Chris M. Thomasson wrote:
 
> In SPARC parlance. For instance, an atomic store on x86 automatically
> implies release. Btw, have you ever worked with SPARC in RMO mode? Its
> fun because its so weak.
 
We discussed it already. I don't think that SPARCv9 RMO hardware
ever existed and you failed to convince me otherwise.
 
As to weakness, I don't think that by specification it is weaker than IPF,
may be not even weaker than POWER. Certainly stronger than Alpha.
But it does not matter since it does not exist.
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 02:06PM -0700

On 9/26/2023 1:58 PM, Michael S wrote:
>> fun because its so weak.
 
> We discussed it already. I don't think that SPARCv9 RMO hardware
> ever existed and you failed to convince me otherwise.
 
Iirc, SPARC64 V9 can put into RMO mode.
 
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 26 02:07PM -0700

On 9/26/2023 1:58 PM, Michael S wrote:
>> fun because its so weak.
 
> We discussed it already. I don't think that SPARCv9 RMO hardware
> ever existed and you failed to convince me otherwise.
 
Have you ever used SPARC before? Solaris?
 
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Monday, September 25, 2023

Digest for comp.programming.threads@googlegroups.com - 1 update in 1 topic

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:

Sunday, September 24, 2023

Digest for comp.lang.c++@googlegroups.com - 6 updates in 2 topics

James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 24 05:19PM -0400

On 9/24/23 14:17, Richard Damon wrote:
> On 9/24/23 12:17 PM, James Kuyper wrote:
>> On 9/24/23 08:04, Richard Damon wrote:
 
...
> Note the emphasis on the word YOU.
 
> The fact THEY don't see how to do it, even after it has been
> demonstrated that it CAN be done, is what is unprofessional.
 
The problem is that Bonita has not recognized those demonstrations as
valid and relevant. That might be because she's misunderstood the
situation (which would be my guess), it might be because she's right, it
might be because you all have explained things to her poorly. However,
unless and until she's been convinced that the specification can be met,
it's entirely appropriate for her to complain about the "fact" that it
can't.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 02:32PM -0700

On 9/24/2023 2:19 PM, James Kuyper wrote:
> unless and until she's been convinced that the specification can be met,
> it's entirely appropriate for her to complain about the "fact" that it
> can't.
 
A mutex that has to jump through atomic hoops during a contended lock
with any "delayed" resource allocation from the kernel is a no go. Bad
design, no good at all.
Richard Damon <Richard@Damon-Family.org>: Sep 24 07:00PM -0400

On 9/24/23 5:19 PM, James Kuyper wrote:
> unless and until she's been convinced that the specification can be met,
> it's entirely appropriate for her to complain about the "fact" that it
> can't.
 
Refusing to accept Truth just puts her in the same league as Peter
Olcott and Flat Earthers. Someone asserting that something that has been
demonstrated isn't true has the burden of proof to actually show their
claim.
 
We have implementations that fully claim to be compliant in this, and
zero cases even hinting that they are in this aspect.
 
Arguing about it is the same as arguing about Russel's Teapot.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 01:06AM +0200

Am 24.09.2023 um 19:10 schrieb Pavel:
 
> so? everyone has been telling you initialization of simple mutices
> does not fail. After few hundred posts, you decided to agree?
 
lock() and unlock() might throw system_error.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 01:10AM +0200

Am 24.09.2023 um 18:47 schrieb Pavel:
> Bonita Montero wrote:
 
> Name one platform for which it is not guaranteed and that targets a
> compliant C++11+ implementation.
 
Any platform since lock() and unlock() might throw system_error()
as documented.
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Sep 25 12:08AM +0200

On 2023-09-24 10:55 AM, JiiPee wrote:
 
>> Easy peasy. :-)
 
>> - Alf
 
> But isnt it that many recommend not to use define's?
 
Yes. But with proper prefixes it's quite clean. Unfortunately the
standard language doesn't yet support pushing/popping macro definitions,
though individual implementations do as language extensions.
 
If you really want to avoid macros, /and/ want that compile time
concatenation really bad, consider something like
 
 
---
namespace my {
template< class Type > using in_ = const Type&;
template< class Type > using ref_ = Type&;
 
template< int n, class Item >
struct Wrapped_array_
{
using Raw = Item[n];
Raw items;
 
constexpr auto raw() const -> ref_<const Raw> { return items; }
};
 
template< int size_a, int size_b >
constexpr auto adjoined( in_<const char[size_a]> a, in_<const
char[size_b]> b )
-> Wrapped_array_<size_a + size_b - 1, char>
{
const int len_a = size_a - 1;
const int len_b = size_b - 1;
const int n = len_a + len_b + 1;
 
Wrapped_array_<n, char> result{};
 
for( int i = 0; i < len_a; ++i ) {
result.items[i] = a[i];
}
for( int i = 0; i < len_b; ++i ) {
result.items[i + len_a] = b[i];
}
result.items[n - 1] = '\0';
return result;
}
} // namespace my
 
#include <stdio.h>
auto main() -> int
{
constexpr auto& a = "abc";
constexpr auto& b = "def";
static constexpr auto c_wrapped = my::adjoined( a, b );
constexpr auto& c = c_wrapped.raw();
 
puts( c );
}
---
 
- Alf
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:

Digest for comp.lang.c++@googlegroups.com - 25 updates in 1 topic

Richard Damon <Richard@Damon-Family.org>: Sep 24 08:04AM -0400

On 9/24/23 7:34 AM, Bonita Montero wrote:
>> believing that.
 
> Someone here cited the standard with that. Everything different
> like spinning (not applicable in userspace) would be unprofessional.
 
Nope, Try to find it.
 
 
You are just showing you don't understand what you are talking about.
 
In fact, using a mutex the way you are decribing, because it can fail,
in "unprofessional", and more importantly, non-conforming.
 
Demanding that specification change because YOU don't see how to meet
them is very much "unprofessional"
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 02:10PM +0200

Am 24.09.2023 um 14:01 schrieb Richard Damon:
 
> But it shouldn't NEED to, since the operation can be done without the
> possibility of error.
 
That isn't guaranteed for any platform.
 
> And, for non-local initialization, it CAN'T.
 
Non-local initializations are done before main() or before the
shared object initialization returns and therefore they don't
need any synchronization.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 02:13PM +0200

Am 24.09.2023 um 14:04 schrieb Richard Damon:
 
> In fact, using a mutex the way you are decribing, because it can
> fail, in "unprofessional", and more importantly, non-conforming.
 
Yielding is unacceptable and the only second solution that sleeps,
as the standard mandates. I don't understand what would be the
problem to have a system_error on a synchronization failure with
static initialization.
Michael S <already5chosen@yahoo.com>: Sep 24 05:21AM -0700

On Sunday, September 24, 2023 at 3:13:21 PM UTC+3, Bonita Montero wrote:
> as the standard mandates. I don't understand what would be the
> problem to have a system_error on a synchronization failure with
> static initialization.
 
I am not an expert in C++ Standard advocacy, rather close to
opposite of, but I can guess. Throwing system_error will create
an illusion of possibility of useful recovery where in reality useful
recovery is impossible.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 02:35PM +0200

Am 24.09.2023 um 14:21 schrieb Michael S:
 
> opposite of, but I can guess. Throwing system_error will create
> an illusion of possibility of useful recovery where in reality
> useful recovery is impossible.
 
This depends on the code you write if this is acceptable. Sometimes
there's also not a useful recovery when a thread responding to another
thread fails to lock a mutex, thereby letting the other thread waiting
forever; nevertheless there's a system_error with that.
Michael S <already5chosen@yahoo.com>: Sep 24 05:47AM -0700

On Sunday, September 24, 2023 at 3:35:46 PM UTC+3, Bonita Montero wrote:
> there's also not a useful recovery when a thread responding to another
> thread fails to lock a mutex, thereby letting the other thread waiting
> forever; nevertheless there's a system_error with that.
 
I don't say that is what should be done.
For me, calling abort() with as intelligible as practical error message is
what should be done on hosted implementation.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 02:51PM +0200

Am 24.09.2023 um 14:47 schrieb Michael S:
 
> I don't say that is what should be done.
> For me, calling abort() with as intelligible as practical error message is
> what should be done on hosted implementation.
 
I _sometimes_ call terminate() on synchronization errors also, f.e. when
a threads responds back to a thread which issued a task to this thread
to prevent starving the other thread. But with the issuing thread first
I don't terminate(). It simply depends on the situation and with static
initialization it's the same.
Daniel <danielaparker@gmail.com>: Sep 24 05:57AM -0700

On Friday, September 22, 2023 at 6:32:02 PM UTC-4, Richard Damon wrote:
 
> The fact that you are too stupid
 
Perhaps Richard could reflect on the fact that with regard to manners and
civility, he's also as stupid as they come. Something to work on. The
heavyweights that used to post here never had that problem.
 
Best regards,
Daniel
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 24 12:27PM -0400

On 9/24/23 08:04, Richard Damon wrote:
> On 9/24/23 7:34 AM, Bonita Montero wrote:
...
> in "unprofessional", and more importantly, non-conforming.
 
> Demanding that specification change because YOU don't see how to meet
> them is very much "unprofessional"
 
No, it is very professional to complain about specifications that can't
be met. What is unprofessional is incorrectly concluding that they
cannot be met (especially after having had it explained to you many times).
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 12:46PM -0400

Bonita Montero wrote:
> cation poblem, i.e. the memory of your object may never be deallocated.
> Show me your implementation !
> It's ridiculous because mutex are a cheap resource.
Cheap as compared to what? How is a mutex "cheaper" than other
synchronization primitives? Also, what exactly mutex operation(s) is/are
cheap? Also, what exactly mutex type is cheap? On what platform? A
blanket statement is never entirely true or false, nothing can be
"ridiculous" because of it.
 
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 12:47PM -0400

Bonita Montero wrote:
 
>> But it shouldn't NEED to, since the operation can be done without the
>> possibility of error.
 
> That isn't guaranteed for any platform.
Name one platform for which it is not guaranteed and that targets a
compliant C++11+ implementation.
 
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 12:53PM -0400

Bonita Montero wrote:
>> believing that.
 
> Someone here cited the standard with that. Everything different
> like spinning (not applicable in userspace) would be unprofessional.
 
Kernel-level sleeping and waking up is more or less moving an execution
context from runlist to a waiting list and back. Why should such an
operation be fail-able?
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 12:59PM -0400

Chris M. Thomasson wrote:
> [...]
 
> I don't think there is a timed wait for a windows critical section. I
> know it has a try, but I cannot remember a timed wait...
It is not a timed wait controlled by the user. But it waits for some
time (specified in the registry) and then fails -- that is its way to
*try* to detect a deadlock. Says the doc on EnterCriticalSection:
 
"
This function can raise EXCEPTION_POSSIBLE_DEADLOCK, also known as
STATUS_POSSIBLE_DEADLOCK, if a wait operation on the critical section
times out. The timeout interval is specified by the following registry
value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\CriticalSectionTimeout. Do not handle a possible deadlock
exception; instead, debug the application.
"
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 01:00PM -0400

Chris M. Thomasson wrote:
>> issue of static C++ initialization).
 
> Iirc, I think a windows critical section might raise an error if its
> been waiting for 30 days or something, deadlocked.
Exactly, that's what I meant, just cited in the other response. It is,
by behavior, a timed recursive mutex but user does not control the time.
Kaz Kylheku <864-117-4973@kylheku.com>: Sep 24 05:04PM

> atomically update the link pointers of the other nodes at the same
> time you update the roots link pointers. And you would have the deallo-
> cation poblem, i.e. the memory of your object may never be deallocated.
 
Now you're just throwing together words you don't understand.
 
> Show me your implementation !
 
E.g. old LinuxThreads in glibc, circa 2000:
 
https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe
 
The low level __pthread_lock and __pthread_unlock functions maintain a
queue, using a single-word atomic CAS.
 
There are suspend() and resume() functions for the waiting;
they are elsewhere.
 
If you look in restart.h you can see that those operations are defined
in two different ways, both of which use signals (not a semaphore per
thread). A suspending thread waits for the arrival of a signal,
resume is done by sending a signal. That's kind of semaphore-like;
and POSIX real-time signals can even queue up, like a counting sem.
 
> It's ridiculous because mutex are a cheap resource. And if such imple-
> mentation would be possible the standard shouldn't mandate it since
> not every platform has a DCAS.
 
Things can be done in ways you havn't thought about.
 
Atomic operations aren't required to achieve mutual exclusion among
processors that share memory.
 
As someone continually insisting on having expertise in concurrency,
you must be familiar with the research work of Leslie Lamport?
 
For instance, the paper _A Fast Mutual Exclusion Algorithm_ [1985].
 
Abstract:
 
"A new solution to the mutual exclusion problem is presented that, in the
absence of contention, requires only seven memory accesses. It assumes
atomic reads and atomic writes to shared registers."
 
Snipeet from Introduction which gives a clue as to the motivation:
 
"Recently, there has arisen interest in building shared-memory
multiprocessor computers by connecting standard processors and
memories, with as little modification to the hardware as possible.
Because ordinary sequential processors and memories do not have atomic
test-and-set operations, it is worth investigating whether
shared-memory mutual exclusion algorithms are a practical alternative."
 
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 01:10PM -0400

Bonita Montero wrote:
>> standard says no such thing.
 
> constexpr mutex() noexcept;
 
> https://en.cppreference.com/w/cpp/thread/mutex/mutex
so? everyone has been telling you initialization of simple mutices does
not fail. After few hundred posts, you decided to agree?
 
>> in user space (like POSIX mutex on linux is created)
 
> If the mutex' constructor is noexcept the kernel-part for the slow
> path has to be initialized delayed while locking.
You can rename your favorite part of locking "initialization" for your
internal use; but it is advisable to use standard terms if you write for
others.
 
Regardless of how it is called, no part of simple mutex lock has to be
fail-able.
 
 
> Rest unread.
yet another broken promise
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:34AM -0700

On 9/24/2023 1:08 AM, Bonita Montero wrote:
> It's ridiculous because mutex are a cheap resource. And if such imple-
> mentation would be possible the standard shouldn't mandate it since
> not every platform has a DCAS.
 
Pardon my French, but that is a rather horrible idea, for several reasons...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:36AM -0700

On 9/24/2023 1:09 AM, Bonita Montero wrote:
>> anyway? ...
 
> Call it std::mutex or whatever. It is mandated that contenders
> are sleeping - that's not possible without sth. else than a mutex.
 
You lost me here.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:41AM -0700

On 9/24/2023 2:50 AM, Michael S wrote:
> waking just fine and initialization of different objects proceeds
> simultaneously just fine. And it does not use mutex for that.
> It uses SleepEx() for wait and QueueUserApc() for wakeup.
 
Why? APC's open up a big can of worms.
 
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:42AM -0700

On 9/24/2023 4:55 AM, Bonita Montero wrote:
> than necessary under load conditions or if not, may actually spin
> and consume unecessary power. So a semaphore is the only solution
> that makes sense.
 
You are all over the place. Sigh. Sorry, Bonita but you are fired from
the team.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:43AM -0700

On 9/24/2023 10:00 AM, Pavel wrote:
>> been waiting for 30 days or something, deadlocked.
> Exactly, that's what I meant, just cited in the other response. It is,
> by behavior, a timed recursive mutex but user does not control the time.
 
Well, in that sense, okay. I see what you are getting at. :^)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:45AM -0700

On 9/24/2023 9:59 AM, Pavel wrote:
> Manager\CriticalSectionTimeout. Do not handle a possible deadlock
> exception; instead, debug the application.
> "
 
Thanks for your clarification. No problem. :^)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:49AM -0700

On 9/24/2023 11:41 AM, Chris M. Thomasson wrote:
>> simultaneously just fine.  And it does not use mutex for that.
>> It uses SleepEx() for wait and QueueUserApc() for wakeup.
 
> Why? APC's open up a big can of worms.
 
Oh shit. I am starting to remember some nightmare code I had to debug
many moon ago that used async cancellation in POSIX threads.
 
 
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:50AM -0700

On 9/24/2023 5:51 AM, Bonita Montero wrote:
> to prevent starving the other thread. But with the issuing thread first
> I don't terminate(). It simply depends on the situation and with static
> initialization it's the same.
 
Oh my god.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 12:08PM -0700

On 9/24/2023 11:49 AM, Chris M. Thomasson wrote:
>>> practicality rather than out of necessity. I am pretty sure that
>>> with enough effort I can device a variant that achieves the same
>>> with CaS.
 
Now, I am recalling async safe sync objects that must be used in a
signal handler for some reason.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at No comments:
Subscribe to: Comments (Atom)