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
<j...@sysmgr.org> wrote:
On Mon, 1 Mar 2021 at 16:45, Reginald Beardsley via oi-dev
<oi-...@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@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#
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
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
