Hey all,
I realized that [shell] seems to be doing some strange things, once I have removed it from my PD the patch runs much better now. I realized this due to a very high chance that a crash would happen just after a shell command is issued.
Has anyone else seen this? I would not cause it a crash per-se, but I can say that oprofile says that no-vmlinux is using 97% CPU, and both PD and X are stalled.
I don't have time to investigate further now, but I'm wondering if other people have seen stability issues with shell on linux for long-term installations?
Thanks all.
FYI I'm back to my 480000 item message... things going ok so far... ;)
.b.
Yeah, [shell] definitely acts strangely sometimes.
.hc
On Nov 26, 2007, at 5:16 PM, B. Bogart wrote:
Hey all,
I realized that [shell] seems to be doing some strange things, once I have removed it from my PD the patch runs much better now. I realized this due to a very high chance that a crash would happen just after a shell command is issued.
Has anyone else seen this? I would not cause it a crash per-se, but I can say that oprofile says that no-vmlinux is using 97% CPU, and both PD and X are stalled.
I don't have time to investigate further now, but I'm wondering if other people have seen stability issues with shell on linux for long-term installations?
Thanks all.
FYI I'm back to my 480000 item message... things going ok so far... ;)
.b.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
On Mon, 26 Nov 2007, Hans-Christoph Steiner wrote:
Yeah, [shell] definitely acts strangely sometimes.
[shell] uses system() instead of the commented-out execvp(). This requires the child to exit by itself. This is done using a call to exit(). exit() calls all exit handlers registered by atexit(), which includes some that are registered by gcc/glibc that call fclose() on all remaining filehandles. fclose() calls fflush() prior to destructing the filehandle. fflush() may contain duplicate data that is sent a second time completely out of sync with what the main process is sending through the same socket. It is the same socket because fork() copies all low-level filehandles (int fd) from one process to the other, with the exact same destination. Thus when the sys_gui() buffer is not empty during a fork(), an exit() will garble the tk command socket's data, which may happen in a way that an open brace is sticking in the air or whatever can freeze pd.tk, i don't know what it is in particular.
I believe that _exit() does not flush the filehandles. The manpage says it closes files, but they must mean only "int fd", whose buffers are shared between all owning processes, unlike "FILE *" buffers.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Indeed lots of message on pd-list about [shell]
So what is the solution?
Me making a bunch of custom call externals for each purpose seems a bit silly. Johannes's method of using a shell server sending commands over a pipe makes sense, but it would be nice to be able to do it from PD proper.
So what is the best solution? Fixing shell or some new external that does a similar job?
Note my tests were using nogui so there would be no tk to "freeze" and I was still getting some pretty bad instabilities.
What I was using shell for:
* executing "xset dpms force suspend" to put the displays to sleep overnight.
Things went totally bad when I tried to get the OS CPU and Memory usage using:
"ps -p `pgrep -o -x pd` h -o %cpu"
or %mem for memory usage.
Ideas?
.b.
Mathieu Bouchard wrote:
On Mon, 26 Nov 2007, Hans-Christoph Steiner wrote:
Yeah, [shell] definitely acts strangely sometimes.
[shell] uses system() instead of the commented-out execvp(). This requires the child to exit by itself. This is done using a call to exit(). exit() calls all exit handlers registered by atexit(), which includes some that are registered by gcc/glibc that call fclose() on all remaining filehandles. fclose() calls fflush() prior to destructing the filehandle. fflush() may contain duplicate data that is sent a second time completely out of sync with what the main process is sending through the same socket. It is the same socket because fork() copies all low-level filehandles (int fd) from one process to the other, with the exact same destination. Thus when the sys_gui() buffer is not empty during a fork(), an exit() will garble the tk command socket's data, which may happen in a way that an open brace is sticking in the air or whatever can freeze pd.tk, i don't know what it is in particular.
I believe that _exit() does not flush the filehandles. The manpage says it closes files, but they must mean only "int fd", whose buffers are shared between all owning processes, unlike "FILE *" buffers.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
B. Bogart -
B. Bogart -
Hans-Christoph Steiner -
Mathieu Bouchard