Bugs item #2905508, was opened at 2009-11-29 00:20
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-11-29 17:47
Message:
It was probably the handles that reached a limit, the threads disappear
after the data has been sent but their handles were not being cleaned up.
Now the threads are created in the detached state so their handles are
freed on exit. On WinXP the handles and threads are fairly constant now.
I'll leave the patch running to see if it ever hangs, but t seems to be
working OK here.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 14:18
Message:
Actually, i couldn't figure out, why it stops working after 380 messages.
I'd like to know, whether it hit some max number of threads limit. I also
couldn't figure out how to display the number of threads being started by a
certain process.I found /proc/sys/kernel/threads-max, which is set to 32491
on my system. However, changing the value doesn't effect the behaviour of
the test-patch.
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 06:03
Message:
The threads are supposed to terminate themselves after they have sent their
buffer. I don't see a need to use threads apart from sending messages. The
rest of [tcpserver] works just fine in one thread.
Here on WinXP the patch is still running at 66000+.
The system is adding handles at about twice the rate as the threads are
being created, but the amount of available memory is not decreasing and the
number of threads is staying about the same.
I'm not sure if that's a bug.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 00:30
Message:
Hm.. from the svn log of revision 12760: "Using pthreads to send each
message to each client in its own thread." That probably explains, why it
stops working after sending X times 'broadcast 97 59 10' to [tcpserver]. Do
i understand right, that literally each pd message opens its own <number of
clients> threads? Wouldn't it be sufficient to have one thread per socket?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2905508, was opened at 2009-11-29 00:20
Message generated for change (Comment added) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
>Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 14:18
Message:
Actually, i couldn't figure out, why it stops working after 380 messages.
I'd like to know, whether it hit some max number of threads limit. I also
couldn't figure out how to display the number of threads being started by a
certain process.I found /proc/sys/kernel/threads-max, which is set to 32491
on my system. However, changing the value doesn't effect the behaviour of
the test-patch.
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 06:03
Message:
The threads are supposed to terminate themselves after they have sent their
buffer. I don't see a need to use threads apart from sending messages. The
rest of [tcpserver] works just fine in one thread.
Here on WinXP the patch is still running at 66000+.
The system is adding handles at about twice the rate as the threads are
being created, but the amount of available memory is not decreasing and the
number of threads is staying about the same.
I'm not sure if that's a bug.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 00:30
Message:
Hm.. from the svn log of revision 12760: "Using pthreads to send each
message to each client in its own thread." That probably explains, why it
stops working after sending X times 'broadcast 97 59 10' to [tcpserver]. Do
i understand right, that literally each pd message opens its own <number of
clients> threads? Wouldn't it be sufficient to have one thread per socket?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2905508, was opened at 2009-11-28 19:20
Message generated for change (Comment added) made by mrpeach
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
>Comment By: Martin Peach (mrpeach)
Date: 2009-11-29 01:03
Message:
The threads are supposed to terminate themselves after they have sent their
buffer. I don't see a need to use threads apart from sending messages. The
rest of [tcpserver] works just fine in one thread.
Here on WinXP the patch is still running at 66000+.
The system is adding handles at about twice the rate as the threads are
being created, but the amount of available memory is not decreasing and the
number of threads is staying about the same.
I'm not sure if that's a bug.
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent)
Date: 2009-11-28 19:30
Message:
Hm.. from the svn log of revision 12760: "Using pthreads to send each
message to each client in its own thread." That probably explains, why it
stops working after sending X times 'broadcast 97 59 10' to [tcpserver]. Do
i understand right, that literally each pd message opens its own <number of
clients> threads? Wouldn't it be sufficient to have one thread per socket?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2905508, was opened at 2009-11-29 00:20
Message generated for change (Comment added) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
>Comment By: Roman Haefeli (reduzent)
Date: 2009-11-29 00:30
Message:
Hm.. from the svn log of revision 12760: "Using pthreads to send each
message to each client in its own thread." That probably explains, why it
stops working after sending X times 'broadcast 97 59 10' to [tcpserver]. Do
i understand right, that literally each pd message opens its own <number of
clients> threads? Wouldn't it be sufficient to have one thread per socket?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2905508, was opened at 2009-11-29 00:20
Message generated for change (Settings changed) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
>Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2905508, was opened at 2009-11-29 00:20
Message generated for change (Tracker Item Submitted) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Nobody/Anonymous (nobody)
Summary: mrpeach/tcpserver: stops sending after X messages
Initial Comment:
After sending 380 messages to one or more clients, [tcpserver] stops sending any more messages. Though TCP is stream-oriented, the number of (pd) messages sent [tcpserver] is significant and not the number of transmitted bytes.
Attached is a patch, that illustrates the problem.
BTW: the new threaded version is ~15 times faster than the old select() based. It looks very promising.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905508&group_…
Bugs item #2905413, was opened at 2009-11-28 13:15
Message generated for change (Comment added) made by mrpeach
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905413&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: messages to clients are doubled
Initial Comment:
hello martin
I was told, that [tcpserver] was updated to use threading now. so i wanted to test the new version. on my machine, it is not working correctly yet. messages sent from [tcpserver] are doubled for some reason. when sending this message with [tcpserver] (it doesn't matter, whether i use the 'send <socketnumber>' or the 'broadcast' method):
97 98 99 100 101 102 103 104 105
i get this on the client side:
97 98 99 100 101 102 103 104 105 97 98 99 100 101 102 103 104 105
sometimes even this:
97 97 98 99 100 101 102 103 104 105 98 99 100 101 102 103 104 105
this is with [tcpserver] compiled from svn checkout from today on pd-0.42.5 on ubuntu 9.10.
----------------------------------------------------------------------
>Comment By: Martin Peach (mrpeach)
Date: 2009-11-28 16:42
Message:
Oops, I hadn't commented out the original unthreaded call to send, so it
was doing both :(
Should work now, at least it does here. Also I added threaded send for
files.
Thanks for testing!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905413&group_…
Bugs item #2905413, was opened at 2009-11-28 18:15
Message generated for change (Settings changed) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905413&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
>Assigned to: Martin Peach (mrpeach)
Summary: mrpeach/tcpserver: messages to clients are doubled
Initial Comment:
hello martin
I was told, that [tcpserver] was updated to use threading now. so i wanted to test the new version. on my machine, it is not working correctly yet. messages sent from [tcpserver] are doubled for some reason. when sending this message with [tcpserver] (it doesn't matter, whether i use the 'send <socketnumber>' or the 'broadcast' method):
97 98 99 100 101 102 103 104 105
i get this on the client side:
97 98 99 100 101 102 103 104 105 97 98 99 100 101 102 103 104 105
sometimes even this:
97 97 98 99 100 101 102 103 104 105 98 99 100 101 102 103 104 105
this is with [tcpserver] compiled from svn checkout from today on pd-0.42.5 on ubuntu 9.10.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905413&group_…
Bugs item #2905413, was opened at 2009-11-28 18:15
Message generated for change (Tracker Item Submitted) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905413&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Nobody/Anonymous (nobody)
Summary: mrpeach/tcpserver: messages to clients are doubled
Initial Comment:
hello martin
I was told, that [tcpserver] was updated to use threading now. so i wanted to test the new version. on my machine, it is not working correctly yet. messages sent from [tcpserver] are doubled for some reason. when sending this message with [tcpserver] (it doesn't matter, whether i use the 'send <socketnumber>' or the 'broadcast' method):
97 98 99 100 101 102 103 104 105
i get this on the client side:
97 98 99 100 101 102 103 104 105 97 98 99 100 101 102 103 104 105
sometimes even this:
97 97 98 99 100 101 102 103 104 105 98 99 100 101 102 103 104 105
this is with [tcpserver] compiled from svn checkout from today on pd-0.42.5 on ubuntu 9.10.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2905413&group_…
Could you post the full pd.tk and the version of Pd its it supposed to
work with? Also:
- I attached a quick stab at turning your scrollbar logic into a 0.43
GUI plugin. It doesn't work because your code relies on Pd-extended
0.42 things, but if you make your algorithm into a plugin using this
framework, then people can just drop the file into the pd/startup
folder to use your algorithm.
- I created a wiki page to document this whole process, please add any
tests that you can think of here:
http://puredata.info/dev/ScrollBarLogic
.hc
On Nov 18, 2009, at 10:37 AM, Ivica Ico Bukvic wrote:
> OK, try the one below instead (with ::scroll call removed). Also,
> plase
> don't forget to do the followign test with large graphics objects and
> test scrollbar behavior:
>
> 1) create iemlib's number2
> 2) adjust its height to 60 and its font size to 50
> 3) drag it as far to the top as possible and what you will likely
> discover is that it fails to reach the top corner *or* creates
> scrollbars even though the object fits comfortably within the window.
> This is not the case AFAIK with the version below.
>
> Ico
>
>
> proc pdtk_canvas_getscroll {name} {
> global pdtk_canvas_mouseup_name
> global pdtk_canvas_mouseup_xminval
> global pdtk_canvas_mouseup_xmaxval
> global pdtk_canvas_mouseup_yminval
> global pdtk_canvas_mouseup_ymaxval
>
> #bbox all is not accurate enough
> #particularly when using large iemlib objects
> #so we calculate canvas size manually
> #set size [$name bbox all]
>
> #borrowed from http://wiki.tcl.tk/4844
> set x1 1.0e30; set x2 -1.0e30 ;
> set y1 1.0e30; set y2 -1.0e30 ;
> foreach item [$name find all] {
> switch -exact [$name type $item] {
> "arc" -
> "line" -
> "oval" -
> "polygon" -
> "rectangle" {
> set coords [$name coords $item]
> foreach {x y} $coords {
> if { $x < $x1 } {set x1 $x}
> if { $x > $x2 } {set x2 $x}
> if { $y < $y1 } {set y1 $y}
> if { $y > $y2 } {set y2 $y}
> }
> }
> }
> }
>
> if {$x1 != 1.0e30} {
>
> set xminval 0
> set yminval 0
> set xmaxval 100
> set ymaxval 20
> #set x1 [lindex $size 0]
> #set x2 [lindex $size 2]
> #set y1 [lindex $size 1]
> #set y2 [lindex $size 3]
>
> #pdtk_post "bbox all: $x1 $x2 $y1 $y2\n"
> #pdtk_post "new bbox all: $xbox1 $xbox2 $ybox1 $ybox2\n"
>
> #these work much better than the ones below
> #they allow for intelligent translation of the canvas
> #rather than introducing redundant scrollbars
> set xminval $x1
> set yminval $y1
>
> set xmaxval [expr $x1+($x2-$x1)]
> set ymaxval [expr $y1+($y2-$y1)]
>
> #if {$x1 < $xminval} {set xminval $x1}
> #if {$y1 < $yminval} {set yminval $y1}
>
> #if {$x2 > $xmaxval} {set xmaxval $x2}
> #if {$y2 > $ymaxval} {set ymaxval $y2}
>
> #pdtk_post "$xminval $xmaxval $yminval $ymaxval\n"
>
> set parentname [winfo parent $name]
> set winwidth [winfo width $parentname]
> set winheight [winfo height $parentname]
>
> set canvaswidth [ expr {abs($xmaxval-$xminval)} ]
> set canvasheight [ expr {abs($ymaxval-$yminval)} ]
> #set canvaswidth [ expr {abs($xminval)+$xmaxval} ]
> #set canvasheight [ expr {abs($yminval)+$ymaxval} ]
>
> #pdtk_post "$canvaswidth $canvasheight\n"
>
> #pdtk_post "$parentname [$parentname.scroll cget -state]\n"
>
> #pdtk_post "scroll=yes $winwidth $canvaswidth\n"
> if {$winwidth > $canvaswidth} {pack forget $parentname.scrollhort}
> if {$winheight > $canvasheight} {pack forget
> $parentname.scrollvert}
> if {$winwidth < $canvaswidth} {pack $parentname.scrollhort -fill
> x \
> -side bottom -before $parentname.c}
> if {$winheight < $canvasheight} {pack $parentname.scrollvert -
> fill y
> \
> -side right -before $parentname.c}
>
>
> if {$pdtk_canvas_mouseup_name != $name || \
> $pdtk_canvas_mouseup_xminval != $xminval || \
> $pdtk_canvas_mouseup_xmaxval != $xmaxval || \
> $pdtk_canvas_mouseup_yminval != $yminval || \
> $pdtk_canvas_mouseup_ymaxval != $ymaxval } {
>
> set newsize "$xminval $yminval $xmaxval $ymaxval"
> $name configure -scrollregion $newsize
> set pdtk_canvas_mouseup_name $name
> set pdtk_canvas_mouseup_xminval $xminval
> set pdtk_canvas_mouseup_xmaxval $xmaxval
> set pdtk_canvas_mouseup_yminval $yminval
> set pdtk_canvas_mouseup_ymaxval $ymaxval
> }
> }
> pdtk_canvas_checkgeometry [canvastosym $name]
> }
>
>
----------------------------------------------------------------------------
"Making boring techno music is really easy with modern tools," he
says, "but with live coding, boring techno is much harder." - Chris
McCormick