x7.35·c wrote:

|Since I am reporting some problems, there is another thing that can |crash PD... |I have 2 PC each running PD and linked together with "netsend" and |"netreceive". The problem is if I instantiate, on the machine which |receives datas, a patch saved on disk inside the patch i am editing, it |crashes PD.

abstractions seem to be problematic generally, ...

Some precisions: If I remove "netreceive 3003" on my top-level patch I can proceed the instantations I want. Then I can re-put "netreceive 3003", then click on the message "connect" on the sender PC and all is fine. Abstractions seem going well otherwise so far.

Francois

| |how abstractions are "generally problematic" I don't know. |Would be insteresting.

i ll see if can reproduce what i was talking about ... ;)

Miller Puckette writes:

I don't know of any interactions between netreceive and abstractions; I'm curious about that.

Well that's the problem with the sockets I'm brabbling about all the time.

If an abstraction is loaded after netreceive has opened a socket, the abstraction filedescriptor will be the same as the sockets fd, (this should not happen, but it does) and select/netreceive freaks out after that, because netreceive thinks it gets connections all the time, (altough the abstractions fd is closed already, netreceive's fd thinks it is litening to a file now).

One (hack) solution would be to let socket fd's range from 100 upwards or so, by using the dup2() or fcntl(F_DUPFD) call. abstraction fd's will be allocated normally

Guenter

Hi Francois,

I've just been loading paf~s into abstractions in the last week... The only thing to watch is that there isn't a path problem; perhaps for some reason the abstraction isn't finding paf~ because the search path in the abstraction is different from that of the "owning" patch. However, I don't know how you would get the paths to be different! What I do in situations like this is to put everything in the same directory, verify that it works that way, and then go back and try to make it work with the files organized "correctly".

By the way, I've just discovered that PAF 0.5 has a problem with clicks if the frequency or bandwidth are changed suddenly. I've fixed that in my copy but you won't see the fix until I get release 0.31 together.

cheers Miller

On Sat, Mar 18, 2000 at 10:32:27PM +0100, F.Ernst wrote:

Hello,

With PD 0.30 I have a problem with paf~

When paf~ is used in an abstraction loaded from the disk included in a patch you get:

paf~ ... couldn't create

But if before that, you load a patch which contains directly a paf~ opcode it will work.

Francois Ernst

|Yes I have modified some lines in the crontab scripts to avoid CPU |hungry behaviours. I didn't dare to kill "crond" but will consider this |if the situation ask for (live act). |But right know I have to stop my work in progress and find a better |solution.

shutting down crond shouldnt be a serious problem, as i dint suppose you re taking your production servers out to perform in the fields? ;) all it does in simple cases is cleaning tmp dirs, removing core files, *~ files and runnnign updatedb oince in a while. or did i forget some critical taks?

|The both PD threads I run respectivly on my 2 machines need a lot of CPU |and it seems that even a too long disk activity can be a threat for |their stability. | |I was using netscape when Pure Data freezed again few minutes ago. | |I am the only one who have theses kind of problems ? Is it linux |specific ?

i m using pd constantly with all sorts of apps open () or other orcesses running and i dare say its never crashed because of system overload. that just shouldnt happen. ?

|I am wondering if the soundcards i use are not a factor. I use a SB 128 |PCI (ens1370) with ALSA in OSS emulation and a fidji.

got the same card thou running with kernel drivers, !alsa ..

|Theses machines have dual cpu main boards but have only one CPU each for |the moment. |May be adding the second one will let PD being less interrupted by other |tasks or devices. I read that in dual cpus machines on linux, one of the |cpu is dealing with the IRQ. It's just an idea.

that sounds more like a place to investigate? have you looked into bios options for single cpu mode or tried a kernel upgrade? we ve had sysfreezes on a dual cpu machine with suse 6.2 or so., that was from 2.2.10 => 2.2.13 ..