Bugzilla Bug 133944

I simply removed dp500.patch, already in 2.7.6 version, from 2.7.5 ebuild

Created an attachment (id=87192) [details]
net-p2p/mldonkey-2.7.6.ebuild

Created an attachment (id=87193) [details]
net-p2p/mldonkey-2.7.6.ebuild

Ops... fixed errors in ebuild header ;)

Please remove the USE flag threads as described in bug #127016

Created an attachment (id=87265) [details]
net-p2p/mldonkey-2.7.6-r1.ebuild

Ok... I've removed threads useflag, I hope the mainteiner likes it ;)

You removed USE Flag threads ?! omg ... did you wrote in the ebuild to use
them? if not, do it, or reenable the use flag ...

(In reply to comment #5)
> You removed USE Flag threads ?! omg ... did you wrote in the ebuild to use
> them? if not, do it, or reenable the use flag ...
> 

Don't panic :)

Quote: "spiralvoice" bug #127016
   "MLDonkey configure activates threads if present (should be
the case on all Gentoo archs)."

Now you can't disable threads using useflag, that's all... mldonkey will always
use threads

The problem was not, that the USE flag "threads" existed, the problem was that
this USE flag _disabled_ thread usage _by default_ which drastically hurts
MLDonkey performance, see bug #127016 for details.

(In reply to comment #7)
> The problem was not, that the USE flag "threads" existed, the problem was that
> this USE flag _disabled_ thread usage _by default_ which drastically hurts
> MLDonkey performance, see bug #127016 for details.

Ok but if we want to keep the threads useflag and enable it by default we
probably  need to add this info in the profile... or not? I'm not sure I can
enable an useflag by default from the ebuild otherwise a possible solution
consists in using a _nothreads_ useflag imho

So well?
If you enabled the threads use flag, mldonkey disabled threads?!

(In reply to comment #9)
> So well?
> If you enabled the threads use flag, mldonkey disabled threads?!

??!!?

So, probably because my bad english, I didn't explain the problem well... I'll
try to use a more schematic approach:

Actually 2.7.5 ebuild
   threads useflag is present, by default a generic useflag is disabled. So if
you want to use threads you need to _explicitly_ enable threads useflag

Proposed solutions for 2.7.6 ebuild
   . we can remove threads useflag and _force_ the use of threads by mldonkey
   . we can remove threads useflag and at the same time add a new nothreads
useflag, so by default mldonkey will use threads and if you want you can
disable this feature enabling nothreads useflag.

I replaied to your question?

Ok thx for Answer :)
Now i understand.

But what is now with this net-p2p/mldonkey-2.7.6-r1.ebuild  ? Here you removed
USE Flag threads. So threads are now enabled by default, yes?

(In reply to comment #11)
> So threads are now enabled by default, yes?

Exactly ;) As spiralvoice said, mldonkey use threads by default if your arch
supported it

This is the configure output (part of interest) on my x86 using
mldonkey-2.7.6-r1.ebuild:

[cut]
----- checking thread support (optional, strongly advised)
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for cc_r... i586-pc-linux-gnu-gcc
[cut]

(In reply to comment #10)
> and if you want you can disable this feature enabling nothreads useflag.

True, but it makes no sense to disable threads in MLDonkey.
Using threads works for years on many platforms without problems
and as said, disabling them seriously hurts performance.

So I would vote for removing USE flag "threads" from MLDonkey ebuild
and let MLDonkey ./configure decide with the help of autoconf macro
ACX_PTHREAD what to do.

(In reply to comment #13)
> So I would vote for removing USE flag "threads" from MLDonkey ebuild
> and let MLDonkey ./configure decide with the help of autoconf macro
> ACX_PTHREAD what to do.

I agree (I wanted to list various solutions in my previous post)

Maintainer, what do you think about it? :)

I like giving people choices on what they want to do. I've been playing around
with mldonkey threads and no-threads to see if there's much performance
difference. I'm going to talk some more with some other architecture leads and
see if threaded support will break anything for them. Sorry for the delay in
response- I was out for a week and a half overseas.

(In reply to comment #15)
> I like giving people choices on what they want to do.
Thats ok, but do not make bad choices the default;-)

Bumped in portage and removed threads USE flag, thanks for help.