X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Received:	by 10.52.36.211 with SMTP id s19mr2554575vdj.7.1402730095213;
	Sat, 14 Jun 2014 00:14:55 -0700 (PDT)
X-Received:	by 10.50.70.100 with SMTP id l4mr295127igu.1.1402730094980; Sat,
	14 Jun 2014 00:14:54 -0700 (PDT)
Newsgroups:	comp.os.msdos.djgpp
Date:	Sat, 14 Jun 2014 00:14:54 -0700 (PDT)
Complaints-To:	groups-abuse AT google DOT com
Injection-Info:	glegroupsg2000goo.googlegroups.com; posting-host=2601:7:f00:2ca:68bd:ef44:670a:8f38;
	posting-account=05hOMwoAAAB6R8xtiQKzEljSMzgOhVF1
NNTP-Posting-Host:	2601:7:f00:2ca:68bd:ef44:670a:8f38
User-Agent:	G2/1.0
MIME-Version:	1.0
Message-ID:	<a121692e-95cf-4038-8cf2-9cfe19b3ff71@googlegroups.com>
Subject:	std::thread, please?
From:	Jim Michaels <jmichae3 AT yahoo DOT com>
Injection-Date:	Sat, 14 Jun 2014 07:14:55 +0000
Bytes:	3479
Lines:	27
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

I would like to see some threads for DJGPP. I write and make use of disk utilities using DJGPP. with some work I suppose I could work around not having threads. but I really could use threads for parallelizing disk i/o calls. 

for instance, wiping disks in parallel or refreshing disks in parallel to save precious time on such long-running processes.

I don't know if I could make use of a timer interrupt or soomething, the protected mode DJGPP uses is not something I have explored much.

perhaps this protected mode could be taken a step further... how about a 64-bit DOS compiler? 64-bit has been around for many years. or are there some factors which make this impossible? a 64-bit DOS compiler could make threads possible...
but there are some hurdles to get through to implement threading and threading contexts on intel processors. some intel procs use cores only. AMD uses cores only from what I remember, so the model is maybe slightly different there.  

windows abstracts away this difference and treats both intel threads and AMD cores as a logical "processor", and each thread runs on a separate processor.

std::thread simply provides a convenient interface to program by that's compatible with much of the standard c++ library.

the biggest differences I can think of offhand would be 
- having both 32 and 64-bit pointers, 
- making some sort of predefined macros for 64-bit vs 32-bit compiler detection, 
- sizeof() reporting correct results for 32 and 64-bit pointers
- function/macro rewrites for conversion of pointers to DOS addresses and back
- documentation rewrites or augmentation
- runtime code differences - obviously there should be a 64-bit target and 32-bit target compiler, unless you can put both into one and use the gcc switch -m32 or -m64 to generate the appropriate target code.
- obvious code generation differences
- threading would enable the very nice auto-speedup optimization combination which parallelizes loops: -ftree-parallelize-loops=0 -floop-parallelize-all  -ftree-slp-vectorize -O2 -fprefetch-loop-arrays
- possible issue: are DOS int21h and int13h calls and int10h calls thread-safe?

this could enable a port of firefox to DOS like people have been wanting? modern browsers are multithreaded.

I would also like to see better integration of extended int13h support and support for video modes that have something other than 80 columns. others do exist.

- Raw text -