[oi-dev] [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!

Reginald Beardsley pulaskite at yahoo.com
Tue Mar 2 03:03:10 UTC 2021


 
In light of the use cases for format(1m) I find it difficult to imagine why it would need to communicate with anything else other than to assert a mutex to prevent other processes from doing something stupid while it ran.

I have the most recent monographs on FreeBSD, Solaris Internals and ZFS arriving later this week.

*If* there is anything worth saying I shall comment once I've read them. But my admiration for Solaris has been severely affected. 

"Tis but a scratch, but it is enough. If you look for me on the morrow, you shall find me a very grave man." With apologies to Will for any failures of my memory.

Reg

     On Monday, March 1, 2021, 07:11:15 PM CST, Joshua M. Clulow <josh at sysmgr.org> wrote:  
 
 On Mon, 1 Mar 2021 at 16:45, Reginald Beardsley via oi-dev
<oi-dev at openindiana.org> wrote:
> 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.

If you take a look, format doesn't create any threads directly -- not
that it would be a problem if it did!

> root at 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 at openindiana:/jack#

Those other threads, beyond the main thread from format that is
crashing, are almost certainly from libsysevent on behalf of the disk
management library.  They are an implementation detail of the door
calls it uses to subscribe to events about devices coming and going in
the system.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20210302/ffd655b2/attachment.html>


More information about the oi-dev mailing list