TManager is a powerful threads/teams/semaphores/ports/areas/images manager for BeOS. If these terms don't sound familiar to you, well, basically TManager deals with everything that's going on in the system or that's loaded in memory.

It was awarded as a runner-up during the first BeOS Master Awards. It was then a much more primitive application.

TManager is aimed at users as well as developers. It mainly serves two purposes: informing the user and enabling him/her to act on the system.

With TManager, you will be able, for example, to:

• know the CPU usage of every thread and every team
• properly quit applications
• set threads priorities
• kill zombie threads and teams
• restart the deskbar or the tracker
• start an emergency terminal

• check that your threads behave as expected
• check that your ports are not getting flooded
• check that the proper add-ons are loaded at the proper time
• understand why your application is hung
• look for message leaks
• look for memory leaks

TManager's main window is composed of two parts. The upper part is the team list. The lower part is, according to the currently selected tab, the list of the selected team's threads, or its semaphores, or ports, or images, or areas. Beneath the team list, two fields show additional information about the selected team: its signature and its full name (which is the path of the executable file). Every list is a multicolumn list. You can change the order of the columns and their width with the mouse: just try clicking and dragging different parts of the column labels. According to the option you selected at the first launch of TManager (show everything or only threads and teams), some tabs may be disabled.

Note that the first team (which is named [kernel space]) is not really a team, in the sense that it doesn't run any thread. It has lots of areas and images, though: these are those that don't pertain to any other team.

Between the two lists, there is a horizontal bevelled line; it looks like the border of a window. In fact you can drag it with the mouse, in order to give more space to one list or the other.

When the window is minimized, TManager sleeps, i.e. it doesn't use any CPU time. This can be very handy if you like to keep a running instance of TManager all the time. Likewise, TManager sleeps when it's not in the current workspace (unless you have disabled this option in the settings panel).

Several actions can be taken on a team, and there are two ways to do that. Either use the pop-up menu (right-click on an item in the team list), or use the Action menu. You can:

• Tell a team to quit. This has much the same effect as selecting the "Quit" option of the application. The application cleanly quits, saving files if necessary. If the team has crashed, or if it's in an unstable state, this command is likely not to work. In this case, try to kill the team.
• Kill a team. Killing a team frees any resources assigned to it (like ports, areas, and the such), so that the system stays clean. However, if there were any open documents in the team, the changes are lost, etc...
• Activate an application. Activating an application brings one of its windows to front. This has no effect on applications that do not have windows.

The team list displays several columns, in addition to the "Team list" column:

• Team ID. This integer uniquely identifies the team.
• Memory usage. Only available if the "show everything" option is checked. This is the amount of memory the team has access to (beware, this figure does not reflect the actual amount of memory the team uses, because of shared memory).
• User time. Amount of time, in microseconds, that this team has spent executing user code.
• Kernel time. Amount of time, in microseconds, that this team has spent executing kernel code.
• Memory usage gauge. Only available if the "show everything" option is checked. Same as memory usage, in a gauge.
• CPU usage gauge. Sum of user time and kernel time, in a gauge.

There are also several ways to act on a thread. Here again you can use a pop-up menu or the Action menu. The following commands are available:

• Kill a thread. Killing a thread has unpredictable effects. It may or may not affect other threads in the same team. The application may also just stop working.
• Wake a thread up. This command only affects those threads whose state is "waiting", "suspended" or "asleep". If the thread is waiting for a semaphore, waking it up will make the acquiring fail. If it is suspended, the thread will be resumed. If it is asleep, it will be literally woken up. Whatever its state, as sson as a thread is woken up, it will be executed, although it may as well return to a passive state right after. If it was waiting for a semaphore and if it's poor code, maybe the thread will also crash if you wake it up, so be careful with this command too.
• Suspend a thread. Dangerous command; the thread often crashes when woken up later.
• Debug a thread. Makes the thread fall into the debugger as soon as it gets out of the kernel. If the thread stays in the kernel, it's maybe in the process of acquiring a semaphore. You can force the thread to enter the debugger by waking it up, but this can cause it to crash if it's poor code, as said before. In my opinion it's a bad idea to wake it up. If you don't do it and if you just type "go" in the debugger, the thread should continue without any problem.
• Alter a thread's priority. This command is perfectly safe (Be has at last fixed the bug with negative priorities). A box appears around the priority: simply enter the new priority.

The thread list also displays several columns, in addition to the "Thread list" column:

• Thread ID. This column is hidden by default. This integer uniquely identifies the thread.
• State. A thread is always in one of the six following states:
  • running: the thread is being executed by a processor
  • waiting: the thread is waiting to acquire a semaphore
  • asleep: the thread sleeps for a given amount of time (in a snooze() call)
  • ready: the thread will be ran as soon as possible
  • receiving: the thread is receiving data (in a receive_data() call)
  • suspending: the thread was suspended or it is freshly spawned
• Priority. The thread's priority determines how often it will be executed.
• User time. Amount of time, in microseconds, that this thread has spent executing user code.
• Kernel time. Amount of time, in microseconds, that this thread has spent executing kernel code.
• Sched. latency. This column is hidden by default. It shows the maximum scheduled latency, in microseconds, of the thread.
• CPU usage gauge. Sum of user time and kernel time, in a gauge.
• Semaphore. ID and name of the semaphore the thread is trying to acquire, if any.

A faster way to edit a thread priority is to click on the priority. This has the same effect as using the menu command.

Two commands relate to semaphores. As usual, they are available in the Action menu and in the pop-up menu.

• Release a semaphore until count is zero. This enables you to release semaphores that are in a blocking state (i.e. whose count are not positive). This command may prove useful if you are debugging your own code, or if you want to solve a deadlock.
• Delete a semaphore. Deletes the semaphore, causing all current acquire_sem() calls to fail.

The semaphore list displays the following columns, in addition to the "Semaphore list" column:

• Semaphore ID. This integer uniquely identifies the semaphore.
• Count. This is NOT the number of threads sitting in an acquire_sem() call. There are three cases:
  • The count is n > &; 0: the next acquire_sem() calls will succeed without any delay.
  • The count is n = &; 0: the next acquire_sem() call will block.
  • The count is n < &; 0: if, for instance, n = -5, it means 5 threads are waiting to acquire the semaphore. The next acquire_sem() call will of course block.
• Latest holder. This is the name of the thread that most recently acquired the semaphore.

There are two commands to act on ports, available through the Action menu or the pop-up menu:

• Close a port. This causes the port to disappear from the list, and it makes it impossible for any thread to write on the port. However, reading is still possible.
• Delete a port. This is more brutal. The name says it all.

The port list displays the following columns, in addition to the "Port list" column:

• Port ID. This integer uniquely identifies the port.
• Capacity. Length of the port's message queue.
• Queue count. Number of messages currently in the queue.
• Total count. Number of messages that have been read from the port.

No command acts on areas. The area list displays the following columns, in addition to the "Area list" column:

• Area ID. This integer uniquely identifies the area.
• Size. Virtual size of the area, in bytes.
• Lock. Indicates whether pages are allowed to be swapped to disk, etc... If you don't understand it, you just don't need it.
• I/O. Tells whether the area is readable, writable, both, or none.
• RAM size. Size, in bytes, of the part of this area that actually occupies memory (the rest is still swapped on the disk).
• Copy count. Straight from the BeBook: "copy_count is a copy-on-write count that can be ignored—it doesn't apply to the areas that you create. The system can create copy-on-write areas (it does so when it loads the data section of an executable, for example), but you can't."
• In count. Number of times at least one page in this area was swapped in from disk.
• Out count. Number of times at least one page in this area was swapped out to disk.

No command acts on images. The image list displays the following columns, in addition to the "Image list" column:

• Image ID. Guess what. :-)
• Type. Can be an application, a library, an add-on or a system image.
• Sequence. The BeBook says, about sequence and init order: "These are zero-based ordinal numbers that give the order in which the image was loaded and initialized, compared to all the other images in this team". I don't know what the difference between sequence and init order is. Maybe sequence is system-wide and init order is team-wide ? This doesn't seem to be what the BeBook says. If you have a clue, please mail me :-)
• Init order. See above.
• Text size. Size, in bytes, of the image's text segment.
• Data size. Size, in bytes, of the image's data segment.

In the Action menu, you will find three additional commands:

• Start a new terminal. Sometimes useful when the system is in an unstable state.
• Launch the Tracker. Sometimes useful when the tracker crashes (hardly happens these days).
• Launch the Deskbar. Same comment.

You can open the settings panel by selecting the corresponding option in the TManager menu. The panel is quite self-explanatory. Here is a list of what you can do:

• Set the refresh rate, between 0.2 Hz and 2 Hz.
• Enable or disable sounds (see the "Setting TManager to use sounds" section, below)
• Tell TManager to collect information about everything, or only about threads and teams. If this option is not checked, all the tabs, except the threads tab, will be disabled. On the other hand, TManager will have a very low CPU usage. It's up to you.
• Set the font (maybe give a try to Monospac821 BT size 10).
• Choose which columns you want to be displayed.
• Tell TManager whether to sleep when its window is not in the current workspace.

Yes, you can use sounds in TManager ! Currently the names are hardcoded. You need to set the path to the sounds in the settings panel. The default directory should be fine. You should then put the files (or symlinks) with the following names in this directory:

• "request quit"
• "kill team"
• "activate app"
• "kill thread"
• "wake thread up"
• "suspend thread"
• "release sem"
• "delete sem"
• "close port"
• "delete port"
• "new terminal"

If you want TManager to be launched on startup, add to your UserBootscript (which should be in /boot/home/config/boot/UserBootscript) something like this:

/boot/apps/TManager minimized &

The "minimized" command-line option will make TManager start in a minimized state. It doesn't consume any CPU time when minimized.

You can also set the priority of the main thread by adding a number in the command-line. For instance:

/boot/apps/TManager minimized 5 &

Here are some tips:

• Don't use the "show everything" mode if you don't need it.
• Minimize TManager when you're not using it. It will not consume any CPU time.
• Use the pop-up menus (some people just seem to be unaware of their existence: right-click in the lists !).
• Don't use the menu to edit priorities: just click on the priority you want to edit, in the list.
• Use sounds and impress your friends. :-)
• If you're sure it's harmless, wake the thread up after applying the "debug thread" command to it.

TManager is shareware. You may use it for 30 days. If you decide to use it after this limit, you *must* register. Besides, the unregistered version has a nagscreen and, what is more important, doesn't save the preferences, nor does it save the widths of the columns, their order, the position and size of the window, whether you use the "show everything" mode or not, and so on...

TManager costs US$12, and you can pay in any currency you like. You will get a lifetime registration, and all updates will automatically be emailed to you.

You may also get a site license (US$200), or a world-wide license (US$800). Their definitions are:

• A Site License allows anyone in the organization making the purchase, within a 160 km (100 mile) radius of the purchasing location, to use the software. This includes people from that organization location who are travelling but it does not include people with locations outside of the 160 km radius.
• A World-Wide License allows anyone in the organization making the purchase, who is on the planet Earth, to use the software.

• By credit card (almost all cards are supported)
• By cheque
• By cash

• You can use the Register TManager application, included with TManager: it is the easy way. The Register application outputs a text that you can send by postal mail, by e-mail, by fax... If you don't plan to use your credit card, this is the only option you have.
• You can also register online via one of these webpages:
  • Secure page: http://order.kagi.com/?V74&S
  • Non-secure page: http://order.kagi.com/?V74

If you decide to use the "Register TManager" application and want to fax the output, use this number:

+1 510 652 6589

If you decide to use the "Register TManager" application and want to mail the output, use this address:

Kagi
1442-A Walnut Street #392-DA
Berkeley, California 94709-1405
USA

After sending your registration info, you will get a confirmation email from Kagi. Then, when in turn I get the information, I will send you a registered version with your name in the About window. The whole process may take up to two full weeks, so please be patient.

You can also directly send a cheque (or cash if you dare) to me at:

Olivier Wittenberg
16 rue des Grands Maîtres
37400 Amboise
FRANCE

Please send comments, bug reports, and the like to witt@micro-video.fr, assuredly I will reply. As you know, feedback is always appreciated.

Version 2.6:

• TManager now has resizable columns, thanks to Brian Tietz's code (which I have modified quite a bit).
• Made the interface navigable.
• User can change the font.
• Added per thread CPU gauges.
• New option: show info about everything or only threads and teams (in this mode, the CPU usage is *really* low: TManager consumes only 2% CPU usage with the *maximum* refresh rate, on my p2-400 — to be compared with 2% in the other mode with the *minimum* refresh rate).
• Data doesn't blink any more when it is refreshed.
• Use of the new BeOS functions to get per team CPU usage.
• Added a nice about window.
• MultiGauge replicant is dead. I did not like it, and anyway, now that Be has added functions to get per team CPU usage, it's no longer useful to get this piece of info from TManager. A separate app would do it at least as well.
• A new TListView (BListView replacement), written from scratch (much faster than BListView... ever tried to add 5000 items to a BListView ?).
• Increased stability (bugfixes).
• New "[kernel space]" pseudo-team.
• New command: "delete sem".
• New command: "close port".
• New command: "suspend thread".
• New column "maximum scheduled latency" in the thread list.
• New option: TManager sleeps when its window isn't in the current workspace.
• Fixed seemingly all memory leaks.
• Lots of minor (and often almost undetectable) changes/bugfixes I have not cared to list.

Version 2.5.4:

First R4 release. Few changes in the application.

Version 2.5.3:

• TManager now also displays the sem_id in the "semaphore" column of the thread list.
• MultiGauge replicant (suggested by Laurent Pontier).
• New action: activate app.
• New action: delete port.
• New action: debug thread (suggested by Brian Tietz).
• New action: release semaphore (suggested by Laurent Pontier & Brian Tietz).
• Settable priority from the command line (suggested by Stephen van Egmond).
• Added the "enable sounds" toggle.
• Use of the new BTabView class.
• Alt-W shortcut has become Alt-U.
• Several minor improvements and bugfixes (gauges, teamlist, other lists...).

Version 2.5.2:

There is no difference between TManager 2.5.1 and TManager 2.5.2 apart from the settings file format, which has been changed to ensure compatibility with the Intel version. Also, 2.5.2 is the first Intel release (hope you like it).

Version 2.5.1:

• The sound playing function has been multithreaded, so that TManager does not crash even though the audio server is in an unstable state.
• A minor bug revealed by B_MALLOC_DEBUG has been fixed (thanks to Sébastien Bouchex, who told me !).

Version 2.5.0:

• TManager now has lists for areas, images, ports, semaphores.
• Each column may individually be enabled or disabled.
• TManager becomes shareware.
• Sounds are played when actions occur.
• A new action has appeared: wake thread up.
• Memory gauges (suggested by Raphaël Moll).
• Several minor bugfixes, and changes in the menus.
• The team list only displays the executable name, not the full path.
• The signature is now displayed.
• A new cool HTML documentation.
• Edit priority box bug fixed (font mismatch).
• More optimization.

• Raphaël Moll (added endian-safe code)
• Till Uro (drew the icon)
• Zeid Derhally (helped me a lot with ppc tests)
• Dario Accornero (helped me with ppc/x86 rsrc/attr issues)
• Laurent Pontier (told me not to drop it all)
• Brian Tietz (made his column list view code public & reported a bug)
• Sebastien Bouchex (reported a bug)