Re: [boinc_dev] addressing some clang warnings
- Messaggio originale -
Da: Alyssa Milburn amilb...@math.leidenuniv.nl
A: Gianfranco Costamagna costamagnagianfra...@yahoo.it
Cc: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
Inviato: Lunedì 8 Luglio 2013 21:52
Oggetto: Re: [boinc_dev] addressing some clang warnings
man fscanf
These functions return the number of input items successfully matched
and assigned, which can be fewer
than provided for, or even zero in the event of an early matching
failure.
The value EOF is returned if the end of input is reached before either
the first successful conversion or
a matching failure occurs. EOF is also returned if a read error occurs,
in which case the error indica‐
tor for the stream (see ferror(3)) is set, and errno is set indicate the
error.
On Mon, Jul 08, 2013 at 04:51:26PM +0100, Gianfranco Costamagna wrote:
- fscanf(f, %d, num_bits);
+ int fs = fscanf(f, %d, num_bits);
+ if (EOF == fs) return ERR_NULL;
key-bits = num_bits;
len = size - sizeof(key-bits);
for (i=0; ilen; i++) {
- fscanf(f, %2x, n);
+ fs = fscanf(f, %2x, n);
key-data[i] = n;
+ if (EOF == fs) return ERR_NULL;
Shouldn't these check that fscanf's result is 1
(e.g. change these to 'if (1 != fs)'?)
I partially agree.
The most appropriate solution should be
if(1 != fs || EOF != fs)
- fscanf(f, %d %d %d %d\n, xpos, ypos,
width, height);
+ if (! fscanf(f, %d %d %d %d\n, xpos,
ypos, width, height)) {
+ fprintf(stderr,Coud not parse parameters for xpos, ypos,
width, height from glx_info file.\n);
+ }
And here shouldn't the check be != 4?
Again
if(4 != fs || EOF != fs)
this way you check if the fscanf finished because of the EOF or not enough
parameters read.
Right?
- Alyssa
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
[boinc_dev] Boinc@android feature request
Simple feature missing from boinc@android: possibility to use swipe action for changing tabs http://developer.android.com/design/patterns/swipe-views.html is it possible/trivial to implement? (please cc me, I'm not subscribed to boinc-android-testing list) thanks Gianfranco ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] addressing some clang warnings
On Tue, Jul 09, 2013 at 08:25:24AM +0100, Gianfranco Costamagna wrote: - fscanf(f, %2x, n); + fs = fscanf(f, %2x, n); key-data[i] = n; + if (EOF == fs) return ERR_NULL; Shouldn't these check that fscanf's result is 1 (e.g. change these to 'if (1 != fs)'?) I partially agree. The most appropriate solution should be if(1 != fs || EOF != fs) That's equivalent to 'if(true)' because fs can't be both 1 and EOF, so either (1 != fs) or (EOF != fs) is true. I think you want an error whenever it is *not* 1, so you just want the (1 != fs): whether it is 0 (failed match) or EOF (ran out of input), you want it to error out. - Alyssa ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] addressing some clang warnings
- Messaggio originale - Da: Alyssa Milburn amilb...@math.leidenuniv.nl A: Gianfranco Costamagna costamagnagianfra...@yahoo.it Cc: steffen_moel...@gmx.de steffen_moel...@gmx.de; boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu Inviato: Martedì 9 Luglio 2013 11:43 Oggetto: Re: [boinc_dev] addressing some clang warnings On Tue, Jul 09, 2013 at 08:25:24AM +0100, Gianfranco Costamagna wrote: - fscanf(f, %2x, n); + fs = fscanf(f, %2x, n); key-data[i] = n; + if (EOF == fs) return ERR_NULL; Shouldn't these check that fscanf's result is 1 (e.g. change these to 'if (1 != fs)'?) I partially agree. The most appropriate solution should be if(1 != fs || EOF != fs) You are right, I mean if(1 == fs || EOF == fs) sorry, I shouldn't send mail in the morning :p G. That's equivalent to 'if(true)' because fs can't be both 1 and EOF, so either (1 != fs) or (EOF != fs) is true. I think you want an error whenever it is *not* 1, so you just want the (1 != fs): whether it is 0 (failed match) or EOF (ran out of input), you want it to error out. - Alyssa ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] addressing some clang warnings
Gesendet: Dienstag, 09. Juli 2013 um 11:47 Uhr Von: Gianfranco Costamagna costamagnagianfra...@yahoo.it An: Alyssa Milburn amilb...@math.leidenuniv.nl Cc: steffen_moel...@gmx.de steffen_moel...@gmx.de, boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu Betreff: Re: [boinc_dev] addressing some clang warnings - Messaggio originale - Da: Alyssa Milburn amilb...@math.leidenuniv.nl A: Gianfranco Costamagna costamagnagianfra...@yahoo.it Cc: steffen_moel...@gmx.de steffen_moel...@gmx.de; boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu Inviato: Martedì 9 Luglio 2013 11:43 Oggetto: Re: [boinc_dev] addressing some clang warnings On Tue, Jul 09, 2013 at 08:25:24AM +0100, Gianfranco Costamagna wrote: - fscanf(f, %2x, n); + fs = fscanf(f, %2x, n); key-data[i] = n; + if (EOF == fs) return ERR_NULL; Shouldn't these check that fscanf's result is 1 (e.g. change these to 'if (1 != fs)'?) I partially agree. The most appropriate solution should be if(1 != fs || EOF != fs) You are right, I mean if(1 == fs || EOF == fs) sorry, I shouldn't send mail in the morning :p And we should bail out before n is assigned to data[i], and if so, data[i] should get (or already have) some not assigned, yet value. Many thanks for the extra eyeballs. Steffen ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] boinc libstdc++ linking
Gesendet: Montag, 08. Juli 2013 um 21:46 Uhr
Von: David Anderson da...@ssl.berkeley.edu
The programs in samples/ are examples of how to build
applications that will run on as many Linux machines as possible,
including those that have old or missing libstdc++.
That's why they statically link libstdc++.a,
and why they have custom Makefiles.
We are experimenting (in Debian experimental) with the boinc-server-maker
package. The samples/* had been built in the past and went into a
package of their own, i.e. boinc-app-examples. As a regular Debian package,
also the boinc-app-examples (samples/*) are auto-built on all the ~11 different
Linux platforms Debian supports. The idea behind it all was to allow
anybody interested in BOINC to have a sample-project configured that allows
multi-platform contributions by not much more than a wget from the Debian
repository.
I have not yet made my mind up about libstdc++. At least for Debian and
Ubuntu, /usr/bin/{boinc,boinccmd} are dynamically linked against libstdc++,
and as such, the beast should already be installed when the app is run.
I do not know about the official BOINC distribution. For the sample apps,
such failures could even be considered educational.
They're not intended to build out of the box,
or to be built by the latest compilers.
They're not built by a top-level configure/make.
I completely understand that there are too busy to care too much corners
in the BOINC code. I have complete confidence that you would accept patches
to bring back compatibility with latest compilers. But, could you sketch for
us to some integration with the - not top-level, but maybe within the
boinc-server realm - build process that you would be prepared to accept?
Cheers,
Steffen
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
Re: [boinc_dev] addressing some clang warnings
Gesendet: Dienstag, 09. Juli 2013 um 00:36 Uhr
Von: David Anderson da...@ssl.berkeley.edu
An: Gianfranco Costamagna costamagnagianfra...@yahoo.it
Cc: boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu
Betreff: Re: [boinc_dev] addressing some clang warnings
Are these changes all thoroughly tested?
-- David
By eye they look fine in the sense that they should not disturb
today's regular operation. The patches did their best in embedding
themselves to the respective error handling philosophy of the
surrounding code and just added a (void) if it was felt that
an error did not want to be detected at all.
I just skimmed through it again, the one here
145 --- a/api/graphics2_unix.cpp
146 +++ b/api/graphics2_unix.cpp
147 @@ -191,7 +191,9 @@
148 FILE *f = boinc_fopen(gfx_info, r);
149 if (f) {
150 // ToDo: change this to XML parsing
151 -fscanf(f, %d %d %d %d\n, xpos, ypos, width, height);
152 +if (! fscanf(f, %d %d %d %d\n, xpos, ypos, width, height)) {
153 + fprintf(stderr,Coud not parse parameters for xpos, ypos,
width, height from glx_info file.\n);
154 + }
155 fclose(f);
156 }
157
is not strict enough, which again is better than not checking at all. It should
check if
the return value of fscanf is != 4 (if I have counted right).
The patch already ships with the latest Debian/Ubuntu package and I am not
aware of any
disturbance to be reported because of it.
Cheers,
Steffen
On 08-Jul-2013 8:51 AM, Gianfranco Costamagna wrote:
Hi David et all,
The following patch address many clang warnings.
Other people can see the patch here
http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=blob;f=debian/patches/more_clang_warnings.patch;h=56bb29543205bdb06e295f5bdc4d3e914dfb96dc;hb=HEAD
The patch is from Steffen Moeller.
thanks
Gianfranco
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
Re: [boinc_dev] addressing some clang warnings
Da: Alyssa Milburn amilb...@math.leidenuniv.nl A: Gianfranco Costamagna costamagnagianfra...@yahoo.it Cc: steffen_moel...@gmx.de steffen_moel...@gmx.de; boinc_dev@ssl.berkeley.edu boinc_dev@ssl.berkeley.edu Inviato: Martedì 9 Luglio 2013 11:43 Oggetto: Re: [boinc_dev] addressing some clang warnings On Tue, Jul 09, 2013 at 08:25:24AM +0100, Gianfranco Costamagna wrote: - fscanf(f, %2x, n); + fs = fscanf(f, %2x, n); key-data[i] = n; + if (EOF == fs) return ERR_NULL; Shouldn't these check that fscanf's result is 1 (e.g. change these to 'if (1 != fs)'?) I partially agree. The most appropriate solution should be if(1 != fs || EOF != fs) That's equivalent to 'if(true)' because fs can't be both 1 and EOF, so either (1 != fs) or (EOF != fs) is true. I think you want an error whenever it is *not* 1, so you just want the (1 != fs): whether it is 0 (failed match) or EOF (ran out of input), you want it to error out. - Alyssa You are absolutely right (sorry I didn't read carefully the mail, my fault) I changed the debian patch based on your suggestions and committed http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commitdiff;h=2b58a04fa4290ef57ea8b06cfc3c353182ad1f26 http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=blob;f=debian/patches/more_clang_warnings.patch;h=a1f0045b5e26a767af59ab450d76409b3a09b3dd;hb=2b58a04fa4290ef57ea8b06cfc3c353182ad1f26 is everything ok now? (write should return -1 in case of failure AFAICS) bests G. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] CPU throttling and GPU apps
The only problem is that there is no real standard for determining the temperature of the CPU (every manufacturer seems to have done it differently. Speed fan is keeping up with this, it is probably not something that BOINC developers really should be attempting to do. -Original Message- From: Charles Elliott [mailto:elliott...@verizon.net] Sent: Tuesday, July 09, 2013 7:15 AM To: McLeod, John; 'David Anderson'; boinc_dev@ssl.berkeley.edu Subject: RE: [boinc_dev] CPU throttling and GPU apps Three of my computers are in a small second floor bedroom with an asphalt roof and a box fan placed in a window close to the ground for its only ventilation. During the afternoons room temperatures are 95 F or higher, too much for the computers. If heat is the problem, it makes more sense to measure CPU/GPU temperatures and reduce the load on a device if the temperature rises above a set point, and increase it if the temps go below a lower set point. I wrote a Java program that does exactly that. It accesses temperatures by parsing a SpeedFan logging file on each computer, and affects Boinc by changing the ncpusN/ncpus line in cc_config.xml and issuing a read_cc_config RPC. Something similar might be possible for the GPUs. It seems to work. Yesterday, its first day of operation, during the afternoon it lowered the CPUs used of the three computers from 8 to 6, and then last night, starting about 10:30, it slowly raised them back to 8, where it is now. Charles Elliott -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of McLeod, John Sent: Monday, July 8, 2013 11:21 AM To: David Anderson; boinc_dev@ssl.berkeley.edu Subject: Re: [boinc_dev] CPU throttling and GPU apps How about changing it to not throttle apps that use less than the current throttling value? E.g. if throttling is set at .9, don't throttle a task that uses .8. -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David Anderson Sent: Friday, July 05, 2013 11:50 PM To: boinc_dev@ssl.berkeley.edu Subject: Re: [boinc_dev] CPU throttling and GPU apps I changed it not throttle apps that use .5 CPUs -- David On 04-Jul-2013 2:38 PM, Eric J Korpela wrote: The only pro I can think of would be to reduce GPU use to keep temperature or power use down, but that would be better implemented as GPU throttling. On Thu, Jul 4, 2013 at 5:52 AM, Bernd Machenschalk bernd.machensch...@aei.mpg.de wrote: On 04.07.13 13:15, Heinz-Bernd Eggenstein wrote: I guess there are several pros and cons, e.g.: cons: - one one hand, GPU apps (depending on the CPU share?) get a higher OS prio (in terms of niceness) to prevent the GPU being starved. Throttling the CPU might very well cause this starvation - if a GPU app has a rather low CPU runtime share in the first place, further CPU throttling does not seem too useful. - in order to avoid GPU load to interfere with the user doing non-BOINC related stuff, there is already the setting Suspend GPU work while computer is in use. Here's one more: When not synchronized with GPU-CPU communication (kernel launches, data transfer) throtteling an App can break any running GPU task. I'm not sure whether the throtteling implementations of all BOINC Clients that are being used properly honor critical sections, nor am I that all GPU apps of all projects make proper use of these. pros: I can't think about many Actually I can't think about any. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Suggestions for resolving bug: could not connect to BOINC
First place to start is http://boinc.ssl.berkeley.edu/trac/wiki/SoftwareDevelopment# -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Caterpillar Sent: Tuesday, July 09, 2013 11:17 AM To: boinc_dev@ssl.berkeley.edu Subject: [boinc_dev] Suggestions for resolving bug: could not connect to BOINC Hello, I am a Fedora user and I am active in Fedora community. I am writing to you to get some good suggestions in fixing a bug we have on Fedora platform. By a year we are having an annoying bug about BOINC manager. Every single time you open it, you will get an error message about could not connect to BOINC https://bugzilla.redhat.com/show_bug.cgi?id=839531 Since the Fedora mantainer of BOINC is very busy and I would like to help him and fix this bug, I need some basic infos about how to begin... because it is the first time I try to approach in fixing a BOINC bug. My C programming skills are medium. This is a Fedora related bug, since I asked to other Linux users and they don't experience this trouble. Thank you for your time. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Suggestions for resolving bug: could not connect toBOINC
Do you happen to know where the patches are for the fedora package? The dialog box displayed in the image attached to the bug report is a customized dialog. It would be helpful to see what other changes have been made to the software. - Rom -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Caterpillar Sent: Tuesday, July 09, 2013 11:17 AM To: boinc_dev@ssl.berkeley.edu Subject: [boinc_dev] Suggestions for resolving bug: could not connect toBOINC Hello, I am a Fedora user and I am active in Fedora community. I am writing to you to get some good suggestions in fixing a bug we have on Fedora platform. By a year we are having an annoying bug about BOINC manager. Every single time you open it, you will get an error message about could not connect to BOINC https://bugzilla.redhat.com/show_bug.cgi?id=839531 Since the Fedora mantainer of BOINC is very busy and I would like to help him and fix this bug, I need some basic infos about how to begin... because it is the first time I try to approach in fixing a BOINC bug. My C programming skills are medium. This is a Fedora related bug, since I asked to other Linux users and they don't experience this trouble. Thank you for your time. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Suggestions for resolving bug: could not connect toBOINC
On Tue, Jul 09, 2013 at 11:25:45AM -0400, Rom Walton wrote: Do you happen to know where the patches are for the fedora package? The dialog box displayed in the image attached to the bug report is a customized dialog. It would be helpful to see what other changes have been made to the software. Looks like http://pkgs.fedoraproject.org/cgit/boinc-client.git/tree/ (the dialog is from boinc-manager-client-notification.patch ) - Alyssa ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] addressing some clang warnings
On Tue, Jul 09, 2013 at 02:46:31PM +0100, Gianfranco Costamagna wrote: I changed the debian patch based on your suggestions and committed http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commitdiff;h=2b58a04fa4290ef57ea8b06cfc3c353182ad1f26 The fscanf(f, .) returns 0 on success (since it matches nothing), so that is still wrong, I guess? Complicated! The '1 == fr' doesn't make much sense to me .. I guess it would be best as '4096 != fr' (if I understand the items correctly)? is everything ok now? (write should return -1 in case of failure AFAICS) I guess if you want to be *perfect* then you could check whether write wrote exactly the right amount (so, 1, in the bit at the end of the patch)? But it's already over-the-top to check all this maybe. :) - Alyssa ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] CPU throttling and GPU apps
Charles: If this program is ready for public use, we could list it here: http://boinc.berkeley.edu/addons.php -- David On 09-Jul-2013 4:15 AM, Charles Elliott wrote: Three of my computers are in a small second floor bedroom with an asphalt roof and a box fan placed in a window close to the ground for its only ventilation. During the afternoons room temperatures are 95 F or higher, too much for the computers. If heat is the problem, it makes more sense to measure CPU/GPU temperatures and reduce the load on a device if the temperature rises above a set point, and increase it if the temps go below a lower set point. I wrote a Java program that does exactly that. It accesses temperatures by parsing a SpeedFan logging file on each computer, and affects Boinc by changing the ncpusN/ncpus line in cc_config.xml and issuing a read_cc_config RPC. Something similar might be possible for the GPUs. It seems to work. Yesterday, its first day of operation, during the afternoon it lowered the CPUs used of the three computers from 8 to 6, and then last night, starting about 10:30, it slowly raised them back to 8, where it is now. Charles Elliott -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of McLeod, John Sent: Monday, July 8, 2013 11:21 AM To: David Anderson; boinc_dev@ssl.berkeley.edu Subject: Re: [boinc_dev] CPU throttling and GPU apps How about changing it to not throttle apps that use less than the current throttling value? E.g. if throttling is set at .9, don't throttle a task that uses .8. -Original Message- From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David Anderson Sent: Friday, July 05, 2013 11:50 PM To: boinc_dev@ssl.berkeley.edu Subject: Re: [boinc_dev] CPU throttling and GPU apps I changed it not throttle apps that use .5 CPUs -- David On 04-Jul-2013 2:38 PM, Eric J Korpela wrote: The only pro I can think of would be to reduce GPU use to keep temperature or power use down, but that would be better implemented as GPU throttling. On Thu, Jul 4, 2013 at 5:52 AM, Bernd Machenschalk bernd.machensch...@aei.mpg.de wrote: On 04.07.13 13:15, Heinz-Bernd Eggenstein wrote: I guess there are several pros and cons, e.g.: cons: - one one hand, GPU apps (depending on the CPU share?) get a higher OS prio (in terms of niceness) to prevent the GPU being starved. Throttling the CPU might very well cause this starvation - if a GPU app has a rather low CPU runtime share in the first place, further CPU throttling does not seem too useful. - in order to avoid GPU load to interfere with the user doing non-BOINC related stuff, there is already the setting Suspend GPU work while computer is in use. Here's one more: When not synchronized with GPU-CPU communication (kernel launches, data transfer) throtteling an App can break any running GPU task. I'm not sure whether the throtteling implementations of all BOINC Clients that are being used properly honor critical sections, nor am I that all GPU apps of all projects make proper use of these. pros: I can't think about many Actually I can't think about any. Best, Bernd ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] boinc libstdc++ linking
Steffen:
You should use apps/uppercase for this purpose.
It's the same as samples/example_app/uc2,
and is built by configure/make.
-- David
On 09-Jul-2013 4:08 AM, Steffen Möller wrote:
Gesendet: Montag, 08. Juli 2013 um 21:46 Uhr
Von: David Anderson da...@ssl.berkeley.edu
The programs in samples/ are examples of how to build
applications that will run on as many Linux machines as possible,
including those that have old or missing libstdc++.
That's why they statically link libstdc++.a,
and why they have custom Makefiles.
We are experimenting (in Debian experimental) with the boinc-server-maker
package. The samples/* had been built in the past and went into a
package of their own, i.e. boinc-app-examples. As a regular Debian package,
also the boinc-app-examples (samples/*) are auto-built on all the ~11 different
Linux platforms Debian supports. The idea behind it all was to allow
anybody interested in BOINC to have a sample-project configured that allows
multi-platform contributions by not much more than a wget from the Debian
repository.
I have not yet made my mind up about libstdc++. At least for Debian and
Ubuntu, /usr/bin/{boinc,boinccmd} are dynamically linked against libstdc++,
and as such, the beast should already be installed when the app is run.
I do not know about the official BOINC distribution. For the sample apps,
such failures could even be considered educational.
They're not intended to build out of the box,
or to be built by the latest compilers.
They're not built by a top-level configure/make.
I completely understand that there are too busy to care too much corners
in the BOINC code. I have complete confidence that you would accept patches
to bring back compatibility with latest compilers. But, could you sketch for
us to some integration with the - not top-level, but maybe within the
boinc-server realm - build process that you would be prepared to accept?
Cheers,
Steffen
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
