TeamForge : Post

Forum Topic - tracelogger:

View: as

Mario Charest

04/10/2008 9:58 AM

post6605

It would be nice if when tracelogger is used in ring mode that it somehow keeps the process and thread names.

While I'm at it, may i suggest that all OS threads be given names, such that when you look at io-net/io-pkt, devb-eide 
and so forth, we have a better idea of who's what;-)

- Mario

Colin Burgess(deleted)

04/10/2008 10:07 AM

post6608

Re: tracelogger

Mario Charest wrote:
> It would be nice if when tracelogger is used in ring mode that it 
> somehow keeps the process and thread names.

Agreed.  It's not quite as simple as it sounds though.  We do have an ongoing project
to do this, but I don't know when it will see the light of day.

> While I'm at it, may i suggest that all OS threads be given names, such 
> that when you look at io-net/io-pkt, devb-eide and so forth, we have a 
> better idea of who's what;-)

I've tried, I've tried.  But alas unless you want to call them "threadpool worker thread 1 etc etc"
I think io-net certainly could use it, but I believe that all threads in io-pkt are generic workers.

> 
> - Mario
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post6605
> 

-- 
cburgess@qnx.com

Mario Charest

04/10/2008 11:08 AM

post6625

Re: tracelogger

> > While I'm at it, may i suggest that all OS threads be given names, such 
> > that when you look at io-net/io-pkt, devb-eide and so forth, we have a 
> > better idea of who's what;-)
> 
> I've tried, I've tried.  But alas unless you want to call them "threadpool 
> worker thread 1 etc etc"
> I think io-net certainly could use it, but I believe that all threads in io-
> pkt are generic workers.
> 

Using "thread pool worker thread 1 et etc" isn't half bad ;-)

Robert Craig

04/10/2008 1:01 PM

post6636

RE: tracelogger

The other pitfall that we have with some of the frameworks outside of the
kernel is that we need to maintain backwards compatibility with versions of
the OS that don't have thread name support in them (although I'm guessing
there's probably a way to work around this).

The io-pkt stack does indeed have a "one thread fits all" model that helps
to boost performance by transitioning between handling hardware directly
into stack processing without a context switch, so naming them wouldn't
really mean that much unless we constantly "renamed" them on the fly (and we
don't think that the performance impact that we'd get rally justifies that
:) ).

	Robert.

-----Original Message-----
From: Mario Charest [mailto:mcharest@zinformatic.com] 
Sent: Thursday, April 10, 2008 11:09 AM
To: ostech-core_os
Subject: Re: tracelogger

> > While I'm at it, may i suggest that all OS threads be given names, such 
> > that when you look at io-net/io-pkt, devb-eide and so forth, we have a 
> > better idea of who's what;-)
> 
> I've tried, I've tried.  But alas unless you want to call them "threadpool

> worker thread 1 etc etc"
> I think io-net certainly could use it, but I believe that all threads in
io-
> pkt are generic workers.
> 

Using "thread pool worker thread 1 et etc" isn't half bad ;-)


_______________________________________________
OSTech
http://community.qnx.com/sf/go/post6625

Roger Maclean

04/10/2008 1:29 PM

post6642

RE: tracelogger

 

> -----Original Message-----
> From: Robert Craig [mailto:rcraig@qnx.com] 
> Sent: April 10, 2008 1:02 PM
> To: ostech-core_os
> Subject: RE: tracelogger
> 
> The other pitfall that we have with some of the frameworks 
> outside of the kernel is that we need to maintain backwards 
> compatibility with versions of the OS that don't have thread 
> name support in them (although I'm guessing there's probably 
> a way to work around this).
> 

The flash player just looks up pthread_setname_np et al using dlsym and uses
them if it finds them.  In theory one should just have to declare the
symbols to be weak and not call them if they're NULL but that appears not to
work.

Return