[PD-dev] [PD] [packOSC] reentrancy problem

[Martin Peach]

Thanks for that. It also works up to a point but it's causing trouble as in
the attached patch. The original message gets scrambled if its payload is
not of the same type as the intervening message.


Also I find that bundles don't actually work. If you try to add another
message to a bundle it fails:

packOSC: According to the type tag (i) I expected more arguments.
packOSC: Problem writing address.
packOSC: According to the type tag I expected an argument of a different
type.
* Expected s, string now in

packOSC: According to the type tag I expected an argument of a different
type.
* Expected s, string now in

packOSC: usage error, write-msg failed.
packOSC: According to the type tag (i) I expected more arguments.
packOSC: Problem closing bundle.


I'm not sure this ever worked or if got broken at some point. Bundles with
one message are fine.


Martin

On Thu, Nov 19, 2015 at 4:53 AM, IOhannes m zmoelnig <zmoelnig at iem.at>
wrote:

> On 2015-11-19 09:49, IOhannes m zmoelnig wrote:
> > to keep the performance of a heap allocated buffer, i would suggest to:
> > - use the original scheme for an "immediate" (non-recursive) message
> > - detect recursion, and if so, allocate buffers on the stack.
>
> attached is a patch that implements that.
> the patch is against current HEAD, though i really worked on HEAD~1, so
> it reverts a number of (imho unneccessary) things.
>
> it only touches functions that actually do output things (minus the
> revert-last-commit),
>
> fgmaf
> IOhannes
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20151119/d32bdfb3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: packOSC-reentrancy-problem.pd
Type: text/x-puredata
Size: 1614 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20151119/d32bdfb3/attachment-0001.bin>