VAULT DWELLERS SERVED

Thursday, February 4, 2016

Protothreads

Was messing around with these last night. Didn't originally understand what I was doing when I looked at these last year. Was thinking about how evil threads are (been doing tons of coding with locking and mutexes) and wondering if my old polling model could be salvaged. Remember once you have solved a deadlock problem you have not solved all the deadlock problems. You have discovered your program can generate a deadlock condition in some situations. After that there will always be peculiar circumstances that can generate deadlocks somewhere in your code. If you pretend it is possible to fix all these situations you are faking it. It isn't. That's threads for you. If you're smart you think of a way to avoid using them except as a process in the OS that runs completely apart and is very loosely coupled to your app. It is the only safe way to expose your program to threading. Plenty of people think if you launch an app and it runs for a couple of months with threads no problem you win. Maybe you do in your context. In Vault-OS we lose if the program crashes in five years. Vault-OS is intended to never crash.

All of a sudden I just "got it." I realized what was happening with these things. Very exciting stuff. In addition to the fact you could definitely run a web server on these things you could also eliminate threads altogether in your design, meaning compiling Vault-OS on an Arduino or ARM board could become a snap.

Another thing. Having written a huge application with SQLite, not sure it was as useful as originally thought. If you could do co-synced threads or protothreads with a single flat file database system that supported in-memory tables, you might have a better option and it might be stabler long term. The journaling system is impressive in SQLite but the in-memory tables have to be shared for read-only amongst all your threads.

So imagine what sort of cross-platform simplicity you could reduce to if you went with the smaller alternatives :

SQLite = 670K + 400K SQL Handling Routines VS. Bullet ISAMic Key-stores with 38K and generic DB4 query system that is up to 1200% faster than SQLite for complex operations.

Pthreads or Winthreads = 470K .DLL (Sometimes larger for dependencies) VS.  30K Protothread library with no thread contention, fully cooperative task sequencing, safe polling for sockets and zero risk of thread contention also runs on all platforms with almost no headaches of any kind.

So the executable of the web server could start to come down drastically in size and maybe fit not just on a floppy but in REAL mode DOS 640K. That would be a real accomplishment. Right now it is getting pretty huge and also presents real problems in cross-platform compilation. I would rather have it compile anywhere on anything but be limited in features rather than be a 40 megabyte server when I have some machines sitting around that only have 64 megabytes (thin clients) to run anything on. For me personally, being able to run VOS on a thin client anywhere is a big plus because at $1.00 a pop on EBay they are the last word in cheap reconfigurable computing devices, perfect for the survivalist budget. You buy ten for terminals and one is modified to run the server, boom plug in a USB we're in operation.

1 comment:

Sam said...

That protothreads guy is interesting. I looked at some of his other stuff and he has the worlds smallest TC/IP. Maybe you've already seen this but you should look at his other software. Especially the Contiki OS for embedded processors.

http://dunkels.com/adam/

papers and books

http://www.contiki-os.org/support.html

You might also look at

https://en.wikipedia.org/wiki/DragonFly_BSD

I think he's doing the same thing or something similar. He forked BSD because of this thread problem.

Something that really interested me when I was looking at OpenBSD was it's use of

https://en.wikipedia.org/wiki/Soft_updates

I thought journaling filesystems were it until heard of this. Why it's not used more I'm not sure. OpenBSD when commenting on why they don't have journaling file system is...they don't need it they have soft updates. Great links in the notes on how this works. Journaling pretends they can't lose any info but if it's cached before written to disk it can lose just like soft updates. Soft updates seems to be much more straight forward and is been around to be stress tested a long time. Journaling is a fad.

www.000webhost.com