First let me say thanks, but also let me see if I got this
right.
Netscape uses threads which in turn use "buzz" locks, (or short
spin locks) for mem locking. (OK)
-> for the sake of argument let say a single Netscape browser
has 2 threads a main thread and a child thread. This child
thread is treated as a "seperate" process by Linux (not sure of
other OSes, but I think NT does not create a seperate process
becuase of process creation/destruction overhead, ie why NT
doesn't have forks in perl yet [so I am told]). If I have 4
browsers open at once then I have 8+ threads and have created 8+
seperate process. is this correct? I should then be able to see
each of these seperate process in /proc (or top/ktop/gtop) ?
wouldn't this create the unnecessary overhead of
creating/destroying a new process every time I start/stop a
thread?
If so what would be the advantage of threads vs forks, other
than shared mem (maybe but couldn't forks also share mem with
locks?)?
If you are using buzz locks then the CPU is spinning waiting
for a lock, for 100 cycles (lets say). If there are multiple
threads in the que waiting for locks (lets say at least 8+),
plus other process, plus I/O to be done thru COM ports (etc),
and X needs to update, could this cause a crash with a failed
I/O request? Assume all process have same priority. On a DUAL
CPU system the CPU could each spin 400+ cycles waiting for
locks. Which would explain Netscape hangs.
Lastly (for now) looking at the kernel source, what info
exactly does the thread_struct store?
Joe
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
