logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

Re: rssowl: libgcj bugs that need fixing for it to run: msg#00279

Subject: Re: rssowl: libgcj bugs that need fixing for it to run
On Wed, 2005-07-27 at 12:16 -0600, Tom Tromey wrote:
> This seems like a reasonable approach when libgcj is linked into the
> resulting executable.  But how can it work if we dlopen() libgcj and
> then attach a previously-existing thread?

It can't; this only solves the problem reported.  We could force tricky
programmers to do thread registrations themselves.  The PyLucene people
probably solved this in some way.

> I was wondering if there was some /proc-reading approach (or something
> like that) that we could use to find information about threads.

Well, I'm guessing that the "[stack]" line /proc/<pid>/task/<pid>/maps
describes the extent of each stack.  Is this an interface we can depend
on over all Linux implementations? (isn't /proc optional during kernel
configuration?)

AG




<Prev in Thread] Current Thread [Next in Thread>