[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference clt::cma

Title:	DECthreads Conference

Moderator:	PTHRED::MARYSTEON

Created:	Mon May 14 1990
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1553
Total number of notes:	9541

1501.0. "Is tset -h in cma_debug() meant to put a thread on hold?" by EDSCLU::GARROD (IBM Interconnect Engineering) Fri Mar 07 1997 16:02

    Is the Ccma_debug() command:
    
    tset -h id
    
    meant to work under Digital UNIX V3.2c. As far as I can see
    it doesn't put a thread into hold state. It continues to run.
    Is this:
    
    a) A bug
    b) A feature
    c) Just my misunderstanding
    
    Thanks,
    
    Dave

T.R Title User Personal
Name Date Lines

1501.1 DCETHD::BUTENHOF Dave Butenhof, DECthreads Mon Mar 10 1997 08:14 15

T.R	Title	User	Personal Name	Date	Lines
1501.1		DCETHD::BUTENHOF	Dave Butenhof, DECthreads	`Mon Mar 10 1997 08:14`	15
	First I'd heard of that. But it turns out that "tset -h" was an old ULTRIX feature that never got implemented on Digital UNIX (although the command was still recognized). That wasn't a deliberate decision -- it just got overlooked, and nobody ever noticed. (It seems very unlikely that it would be worthwhile to try to patch 3.2C at this point, just because one person finally noticed.) It appears to work again on 4.0 -- again, purely by accident, because of the way the scheduler has changed. (Actually, ladebug uses a special proc ioctl flag to resume the process after a breakpoint, which causes a "resched" event in each kernel thread, allowing our scheduler to refresh the state; "tset" in other debuggers might not work reliably for running threads unless they also use that flag.) /dave

First I'd heard of that. But it turns out that "tset -h" was an old ULTRIX
feature that never got implemented on Digital UNIX (although the command was
still recognized). That wasn't a deliberate decision -- it just got
overlooked, and nobody ever noticed. (It seems very unlikely that it would be
worthwhile to try to patch 3.2C at this point, just because one person
finally noticed.)

It appears to work again on 4.0 -- again, purely by accident, because of the
way the scheduler has changed. (Actually, ladebug uses a special proc ioctl
flag to resume the process after a breakpoint, which causes a "resched" event
in each kernel thread, allowing our scheduler to refresh the state; "tset" in
other debuggers might not work reliably for running threads unless they also
use that flag.)

	/dave