3 ms·
Probably not .. that is a diminishing returns kind of thing. If I'm the only user and there are not a lot of programs that need it, it's not worth the effort.
by mbbrutman 4y ago
Probably not .. that is a diminishing returns kind of thing. If I'm the only user and there are not a lot of programs that need it, it's not worth the effort.
What I have now can best be described as cooperative multitasking with custom contexts. Example: the FTP server and HTTP server keep track of each user connection, provide them a buffer, and know the state of the session and how far into the file they are that is being transferred. (True multithreading would generalize that kind of context as a set of registers and a stack for each thread.)
- MrYellowP 4y agoI am talking about actual multithreading using several cores. You don't need to write a scheduler for that or anything fancy. There's some osdev tutorials about how to enable multiple cores in DOS, iirc. I can dig them out, if you want. You're probably seriously overthinking this. Right now you're polling, which is fine, because that's how all the high performance software works. One thread pre core, each thread rolling through a list of connections, checking if there's new data.
- mbbrutman 4y agoOh, I understood - I've been a professional programmer for close to 30 years, and I've done a lot of operating systems work. On this platform you have the burden of ensuring that the C runtime is thread safe, or putting locks around it. The same with BIOS calls. And DOS function calls too; you can't have those other CPU cores just blundering in on something that is not reentrant. And besides, I target this at 16 bit DOS on vintage machines. I've never seen a PCjr or an AT class machine with multiple cores. There were some super expensive 386s at the time that were multi-processors, but those are a fairly rare item.