It is with deep regret that I say this. I shall not be working on Illumos/OI. Below is the terminal output using the Hipster 2020.10 GUI install disk. I've always been amused by the enthusiasm for threads. I bought John Lakos' book when it came out and unlike most actually read much of it. I even posted a page on my office door. Many months after I'd taken it down the entire project ground to a complete halt while they refactored the sysem to address the linker issue I'd highlighted on my office door. I've also read many books on operating systems and all the issues that must be handled 100% correctly to make multiple processes running in the same address space work reliably. Can you state the "Dining Philospher's" problem? I can. This stuff is hard. That's why protected memory is so important to a robust system. Threads, like shared memory are valuable tools, but are best used with discretion. And only when there is no suitable alternative.
Rather well known, at least to my generation, is something called "Amdahl's law". It's not particularly insightful. It just makes the observation that pefectly optimizing something which does not take a lot of time has neglegible benefit. That a seldom used admin utility would be rewritten as a threaded application says that those responsible for this idiocy were solely interested in adding "threaded programming" to their resumes. I neither know nor care if the programmer was at fault or the manager who permitted it was at fault. In any case it is so stupid as to begger belief. Sadly I have seen many people do something similar. I have *never* written a program using pthreads or any other threading library. I dealt with things like seismic imaging problems which ran on 10,000 -20,000 cores or more for 8-10 days processing 10-30 TB of input and generating similar output volumes. Fortunately these were trivially parallel and could be broken up into separate jobs for each core. With that many machines running, checkpointing and restarting was a critical issue. You *were* going to lose a few machines during a run. So robust recovery was a big deal. That much compute costs a lot of money and starting the whole thing over simply not viable. If you did, you went out of business. The only upside was because such users were running 50,000 cores 24x7 in a single location, they got baseload electrical rates. Though it was not uncommon to have to find additonal locations because the electrical power feed to that location had been exceeded. In Houston, the AC costs as much or more than the computers to run. I've seen an inappropriate tool used far too many times for the sole reason that some one wanted to put something on their resume. For many years I'd never written an IP based client server application. I'd taught other people how to do it, but I had not done it myself for the simple reason that it was not an appropriate tool for my assigned tasks. I did eventually get to write a UDP usage logger that tracked usage statistics for the package we were fielding. That was fun. I generated graphics that showed where each business affiliate was in the exploration cycle from what programs they were running. Much too my surprise and some dismay, Mac OS X is the best supported commercial Unix today. So I may well become a Mac user. A not very happy, Reg jack@openindiana:/jack$ sudo /bin/su root@openindiana:/jack# format -e Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c4d0 <drive type unknown> /pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0 Specify disk (enter its number): 0 Error: can't open disk '/dev/rdsk/c4d0p0'. Segmentation Fault (core dumped) root@openindiana:/jack# pstack core core 'core' of 3749: format -e --------------------- thread# 1 / lwp# 1 --------------------- 080658cb init_globals (8095bd8, 0, 8047d18, 806837c, 0, fefc3bb9) + 51f 08068385 c_disk (fef70548, fef70548, 3, 2, 4, 806d608) + 3c8 08065bc1 main (8047d6c, fef685c8, 8047da8, 8057e47, 2, 8047dd4) + 2b4 08057e47 _start_crt (2, 8047dd4, fefd0c6f, 0, 0, 0) + 96 08057d1a _start (2, 8047eb4, 8047ebb, 0, 8047ebe, 8047ed2) + 1a --------------------- thread# 2 / lwp# 2 --------------------- feeed05e __door_return (0, 0, 0, 0, feb90240, fef5b000) + 2e feed287c door_create_func (0) + 4a feee7551 _thrp_setup (feb90240) + 81 feee7800 _lwp_start (feb90240, 0, 0, 0, 0, 0) --------------------- thread# 3 / lwp# 3 --------------------- feee7859 __lwp_park (8097828, 8097838, 0, 0, 0, 0) + 19 feee1607 cond_wait_queue (8097828, 8097838, 0) + 5f feee1d82 __cond_wait (8097828, 8097838) + b1 feee1e1c cond_wait (8097828, 8097838) + 2e fe8a4986 subscriber_event_handler (8095ce0) + 9d feee7551 _thrp_setup (feb90a40) + 81 feee7800 _lwp_start (feb90a40, 0, 0, 0, 0, 0) root@openindiana:/jack# _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
