On Tue, Jun 13, 2006 at 10:26:55PM +0300, Jusa Saari wrote:
> On Tue, 13 Jun 2006 18:53:35 +0100, Matthew Toseland wrote:
> 
> > On Mon, Jun 12, 2006 at 08:32:52PM +0300, Jusa Saari wrote:
> >> On Mon, 12 Jun 2006 12:15:54 +0200, Jerome Flesch wrote:
> >> 
> >> >> Finally, why does FUQID need replacing ? I thought it was working
> >> >> just fine, even on Freenet 0.7 ?
> >> >>
> >> > It works only under Windows. And no, Wine is *not* a solution, because
> >> > it works only on Linux 32bits, and so Mac OS[X] users and Linux 64bits
> >> > users (amd64) can't use Fuqid.
> >> 
> >> I was under the impression that Freenet itself doesn't works so well
> >> under 64-bit Linux, since that doesn't support non-native Posix threads,
> >> leading to a deadlock.
> > 
> > Purely a temporary problem, and in any case as long as the wrapper works
> 
> Actually, if this problem is indeed caused by interaction between Java and
> NPTL, it has been around for years and shows no signs of going away. From
> what I've understood, the problem is caused by a bug in NPTL, and until
> that is fixed or JVM is rewritten to work around it, the problem persists.

Well... yeah. Modulo GCJ.
> 
> > (does it?), the node will be auto-restarted when it hangs. This is why we
> > have disabled the LD_ASSUME_KERNEL hack on new installs; it's not
> > necessary as long as the wrapper and the watchdog work.
> 
> What happens if the watchdog gets stuck too ? It has to synchronize with
> the watched thread sometimes to do its work, AFAIK.

It just reads a variable. An int. Without synchronization.
> 
> Besides, when the node gets restarted, all pending requests are lost,
> aren't they ? That means that constant rebstarts can't be good for network
> health. They are likely to break at least some client applications, too.

True, but as long as it's relatively rare that's ok.
> 
> Is there any specific penaly for using non-native Posix threads ? I was
> under the impression that the major advantage to NPTL was thread creation
> speed, and Freenet doesn't constantly create new threads, or does it ?

They're scheduled as one process, so we can use thread priorities... we
do create lots of new threads, but I dunno, they seem faster.
> 
> >> Besides, can't 64-bit Linux run 32-bit programs, if the correct
> >> libraries are installed ?
> > 
> > That's an awful lot of work for the user...
> 
> I'm pretty certain that most 64-bit distros have 32-bit libraries
> installed by default, since to do otherwise would make them completely
> unable to use any program for which source code is not available, or whose
> author made unwarranted assumptions about pointer size.

Well sure but 32-bit wine?
-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to