I simply removed dp500.patch, already in 2.7.6 version, from 2.7.5 ebuild
Created attachment 87192 [details] net-p2p/mldonkey-2.7.6.ebuild
Created attachment 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 attachment 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.
