liblo-devel Mailing List for LibLO

Hi,

  I'm trying to install the Liblo Library on Windows using Cygwin.  I can
get the configure stage of the Installation to work but I am having some
trouble executing the 'make' commands. This is likely a Cygwin problem
rather than a Liblo problem, however if you have experienced this issue
before I would greatly appreciate any help.

Thanks in advance,

Connor Reid

Steve,

Le 26/03/12 22:03, Stephen Sinclair a écrit :
> Hello,
>
> Yes it's in progress.  I have had to take a break on it for a few
> weeks since I have a deadline coming up, but I plan to try getting the
> last features and bugs for 0.27 fixed by some time in May.
thanx for that info
++
>
> Steve
>
> On Mon, Mar 26, 2012 at 12:18 PM, nico<sl1...@gm...>  wrote:
>> hi,
>> is there is any plan for liblo 0.27 in a near future?
>> Best regards,
>> Nicolas
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hello,

Yes it's in progress.  I have had to take a break on it for a few
weeks since I have a deadline coming up, but I plan to try getting the
last features and bugs for 0.27 fixed by some time in May.

Steve

On Mon, Mar 26, 2012 at 12:18 PM, nico <sl1...@gm...> wrote:
> hi,
> is there is any plan for liblo 0.27 in a near future?
> Best regards,
> Nicolas
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

hi,
is there is any plan for liblo 0.27 in a near future?
Best regards,
Nicolas

Hello Steve,

Just to confirm that the fix your committed works for me.

Thanks!
Cam


On 2 mars 2012, at 18:14, Stephen Sinclair wrote:

> Okay I finally understand what is happening, and it is nice to catch
> this problem because it seems to be due to liblo fundamentally not
> handling the listening socket correctly in terms of blocking
> behaviour.
> 
> What is supposed to happen:
> 
> lo_server_recv_noblock(): wait a maximum time (may be 0) for at least
> one message
> lo_server_recv(): wait as long as required for at least one message
> 
> Unfortunately lo_server_wait() does not have a handler for when a new
> connect is accepted, it returns as if a message is ready.
> Therefore when lo_server_recv_noblock() calls lo_server_wait(), it
> assumes a message is ready and calls lo_server_recv(), assuming it
> will not block.  However, lo_server_recv() accepts the connection and
> then tries to read.  Adding the loop only made it go back and block on
> select()/poll().
> 
> Problem: The internal function lo_server_recv_raw_stream() is called
> from lo_server_recv(), and lo_server_recv() is called from
> lo_server_recv_noblock() (which assumes lo_server_recv() will not
> block.)  Unfortunately lo_server_recv_raw_stream() therefore has no
> way to know whether it is being called with blocking or non-blocking
> semantics.
> 
> I think the fix is to ensure that lo_server_recv() is never called
> unless a message is truly ready.  That means that new connections must
> be accepted in lo_server_wait(), and it must not return after
> accept(), but only after either an error or a data socket is ready.
> 
> I applied a patch to this effect on the svn trunk.  Please test!
> I've tested on Ubuntu 10.10 and OS X 10.6.8, so far so good.
> 
> Steve

That's great Steve, and thank you for the analysis.
I will report my test shortly.


On 2 mars 2012, at 18:14, Stephen Sinclair wrote:

> Okay I finally understand what is happening, and it is nice to catch
> this problem because it seems to be due to liblo fundamentally not
> handling the listening socket correctly in terms of blocking
> behaviour.
> 
> What is supposed to happen:
> 
> lo_server_recv_noblock(): wait a maximum time (may be 0) for at least
> one message
> lo_server_recv(): wait as long as required for at least one message
> 
> Unfortunately lo_server_wait() does not have a handler for when a new
> connect is accepted, it returns as if a message is ready.
> Therefore when lo_server_recv_noblock() calls lo_server_wait(), it
> assumes a message is ready and calls lo_server_recv(), assuming it
> will not block.  However, lo_server_recv() accepts the connection and
> then tries to read.  Adding the loop only made it go back and block on
> select()/poll().
> 
> Problem: The internal function lo_server_recv_raw_stream() is called
> from lo_server_recv(), and lo_server_recv() is called from
> lo_server_recv_noblock() (which assumes lo_server_recv() will not
> block.)  Unfortunately lo_server_recv_raw_stream() therefore has no
> way to know whether it is being called with blocking or non-blocking
> semantics.
> 
> I think the fix is to ensure that lo_server_recv() is never called
> unless a message is truly ready.  That means that new connections must
> be accepted in lo_server_wait(), and it must not return after
> accept(), but only after either an error or a data socket is ready.
> 
> I applied a patch to this effect on the svn trunk.  Please test!
> I've tested on Ubuntu 10.10 and OS X 10.6.8, so far so good.
> 
> Steve
> 
> 
> On Thu, Mar 1, 2012 at 6:05 PM, Stephen Sinclair <rad...@gm...> wrote:
>> Just a quick note to mention that I managed to reproduce this with a
>> small test. (on Linux)
>> 
>> Test program is attached.
>> If you run it with an argument "test", it will send a data packet
>> before listening on the socket.  Otherwise it will connect but not
>> send a packet yet, and it seems to never exit the first call to
>> lo_server_recv_noblock().
>> 
>> $ ./test test
>> Testing.
>> Connected
>> Sending data 1.
>> path: /aa
>> Sending data 2.
>> path: /bb
>> 
>> $ ./test
>> Testing.
>> Connected
>> <hangs here... expected to see "Sending data 2.">
>> 
>> Clearly a bug.
>> 
>> Steve
>> 
>> 
>> On Tue, Feb 28, 2012 at 5:01 PM, Camille Troillard
>> <ca...@os...> wrote:
>>> 
>>> On 28 févr. 2012, at 22:39, Stephen Sinclair wrote:
>>> 
>>>>> lo_server_recv blocks when a connection is made from a client to the server because the server tries to read data just after the socket is accepted, even though there is no data to read yet. After the client send its first message to the server everything comes back to normal.
>>>> 
>>>> Thanks for that information, that's definitely more descriptive of the
>>>> problem.  So there's certainly some broken semantics there, I would
>>>> not expect lo_server_recv() to block after lo_server_wait(), and
>>>> lo_server_recv_noblock() should certainly never block.
>>> 
>>> Yes.
>>> 
>>> 
>>>> I'll try writing a test for these conditions and go from there.
>>>> Certainly your patch is problematic unfortunately, because it sort of
>>>> creates an opposite problem where lo_server_recv() can return without
>>>> blocking, which is against the expectations of some user code.
>>>> Generally lo_server_recv() should always return a message if one is
>>>> available, but with your patch it returns without reading it.
>>> 
>>> Ahhh right, I overlooked that.
>>> 
>>> 
>>>> That's why I made it call back to select() again to check if there is data to
>>>> read before forcing a read() call.  I'm surprised that it still blocks
>>>> for you in that case -- the two possible conditions, as far as I can
>>>> see are:
>>>> 
>>>> * client makes a connection, no data
>>>> -> server accepts connection, select() says there is no data
>>> 
>>> On Mac OS X, poll is used and blocks until data is present (server.c, line 695).  If however I force the use of select, the application hangs on select (server.c, line 726).
>>> 
>>> 
>>>> * cilent makes a connection, sends data
>>>> -> server accepts connection, select() says there is data, call read()
>>>> 
>>>> What is happening in your program that is not one of these two cases?
>>>> Somehow read() is getting called when there is no data, even though
>>>> read() is only called after select() says there is data, so there must
>>>> be some very subtle thing going on here.
>>> 
>>> This time read is not called, which is fine.
>>> 
>>> 
>>>> Question: what does your client code look like? The only thing I still
>>>> find confusing is that you say, "the server tries to read data just
>>>> after the socket is accepted, even though there is no data to read
>>>> yet."  However, afaik there is no way for liblo client to make a
>>>> connection to a server without sending a message, so there should
>>>> always be a packet of data to read after accept().  Maybe another OSC
>>>> clients may behave differently though..
>>> 
>>> The client code is a TCP client written in Cocoa with the VVOSC library, but only the encoding functions are used.  The networking code is handled by a NSSocket, which is basically a wrapper around unix sockets.  I understand that using liblo would not cause this problem to happen, but here the code is used in another developer's application, which makes me believe the problem is legitimate.
>>> 
>>> 
>>> Cam
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> 

Okay I finally understand what is happening, and it is nice to catch
this problem because it seems to be due to liblo fundamentally not
handling the listening socket correctly in terms of blocking
behaviour.

What is supposed to happen:

lo_server_recv_noblock(): wait a maximum time (may be 0) for at least
one message
lo_server_recv(): wait as long as required for at least one message

Unfortunately lo_server_wait() does not have a handler for when a new
connect is accepted, it returns as if a message is ready.
Therefore when lo_server_recv_noblock() calls lo_server_wait(), it
assumes a message is ready and calls lo_server_recv(), assuming it
will not block.  However, lo_server_recv() accepts the connection and
then tries to read.  Adding the loop only made it go back and block on
select()/poll().

Problem: The internal function lo_server_recv_raw_stream() is called
from lo_server_recv(), and lo_server_recv() is called from
lo_server_recv_noblock() (which assumes lo_server_recv() will not
block.)  Unfortunately lo_server_recv_raw_stream() therefore has no
way to know whether it is being called with blocking or non-blocking
semantics.

I think the fix is to ensure that lo_server_recv() is never called
unless a message is truly ready.  That means that new connections must
be accepted in lo_server_wait(), and it must not return after
accept(), but only after either an error or a data socket is ready.

I applied a patch to this effect on the svn trunk.  Please test!
I've tested on Ubuntu 10.10 and OS X 10.6.8, so far so good.

Steve


On Thu, Mar 1, 2012 at 6:05 PM, Stephen Sinclair <rad...@gm...> wrote:
> Just a quick note to mention that I managed to reproduce this with a
> small test. (on Linux)
>
> Test program is attached.
> If you run it with an argument "test", it will send a data packet
> before listening on the socket.  Otherwise it will connect but not
> send a packet yet, and it seems to never exit the first call to
> lo_server_recv_noblock().
>
> $ ./test test
> Testing.
> Connected
> Sending data 1.
> path: /aa
> Sending data 2.
> path: /bb
>
> $ ./test
> Testing.
> Connected
> <hangs here... expected to see "Sending data 2.">
>
> Clearly a bug.
>
> Steve
>
>
> On Tue, Feb 28, 2012 at 5:01 PM, Camille Troillard
> <ca...@os...> wrote:
>>
>> On 28 févr. 2012, at 22:39, Stephen Sinclair wrote:
>>
>>>> lo_server_recv blocks when a connection is made from a client to the server because the server tries to read data just after the socket is accepted, even though there is no data to read yet. After the client send its first message to the server everything comes back to normal.
>>>
>>> Thanks for that information, that's definitely more descriptive of the
>>> problem.  So there's certainly some broken semantics there, I would
>>> not expect lo_server_recv() to block after lo_server_wait(), and
>>> lo_server_recv_noblock() should certainly never block.
>>
>> Yes.
>>
>>
>>> I'll try writing a test for these conditions and go from there.
>>> Certainly your patch is problematic unfortunately, because it sort of
>>> creates an opposite problem where lo_server_recv() can return without
>>> blocking, which is against the expectations of some user code.
>>> Generally lo_server_recv() should always return a message if one is
>>> available, but with your patch it returns without reading it.
>>
>> Ahhh right, I overlooked that.
>>
>>
>>> That's why I made it call back to select() again to check if there is data to
>>> read before forcing a read() call.  I'm surprised that it still blocks
>>> for you in that case -- the two possible conditions, as far as I can
>>> see are:
>>>
>>> * client makes a connection, no data
>>> -> server accepts connection, select() says there is no data
>>
>> On Mac OS X, poll is used and blocks until data is present (server.c, line 695).  If however I force the use of select, the application hangs on select (server.c, line 726).
>>
>>
>>> * cilent makes a connection, sends data
>>> -> server accepts connection, select() says there is data, call read()
>>>
>>> What is happening in your program that is not one of these two cases?
>>> Somehow read() is getting called when there is no data, even though
>>> read() is only called after select() says there is data, so there must
>>> be some very subtle thing going on here.
>>
>> This time read is not called, which is fine.
>>
>>
>>> Question: what does your client code look like? The only thing I still
>>> find confusing is that you say, "the server tries to read data just
>>> after the socket is accepted, even though there is no data to read
>>> yet."  However, afaik there is no way for liblo client to make a
>>> connection to a server without sending a message, so there should
>>> always be a packet of data to read after accept().  Maybe another OSC
>>> clients may behave differently though..
>>
>> The client code is a TCP client written in Cocoa with the VVOSC library, but only the encoding functions are used.  The networking code is handled by a NSSocket, which is basically a wrapper around unix sockets.  I understand that using liblo would not cause this problem to happen, but here the code is used in another developer's application, which makes me believe the problem is legitimate.
>>
>>
>> Cam
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Just a quick note to mention that I managed to reproduce this with a
small test. (on Linux)

Test program is attached.
If you run it with an argument "test", it will send a data packet
before listening on the socket.  Otherwise it will connect but not
send a packet yet, and it seems to never exit the first call to
lo_server_recv_noblock().

$ ./test test
Testing.
Connected
Sending data 1.
path: /aa
Sending data 2.
path: /bb

$ ./test
Testing.
Connected
<hangs here... expected to see "Sending data 2.">

Clearly a bug.

Steve


On Tue, Feb 28, 2012 at 5:01 PM, Camille Troillard
<ca...@os...> wrote:
>
> On 28 févr. 2012, at 22:39, Stephen Sinclair wrote:
>
>>> lo_server_recv blocks when a connection is made from a client to the server because the server tries to read data just after the socket is accepted, even though there is no data to read yet. After the client send its first message to the server everything comes back to normal.
>>
>> Thanks for that information, that's definitely more descriptive of the
>> problem.  So there's certainly some broken semantics there, I would
>> not expect lo_server_recv() to block after lo_server_wait(), and
>> lo_server_recv_noblock() should certainly never block.
>
> Yes.
>
>
>> I'll try writing a test for these conditions and go from there.
>> Certainly your patch is problematic unfortunately, because it sort of
>> creates an opposite problem where lo_server_recv() can return without
>> blocking, which is against the expectations of some user code.
>> Generally lo_server_recv() should always return a message if one is
>> available, but with your patch it returns without reading it.
>
> Ahhh right, I overlooked that.
>
>
>> That's why I made it call back to select() again to check if there is data to
>> read before forcing a read() call.  I'm surprised that it still blocks
>> for you in that case -- the two possible conditions, as far as I can
>> see are:
>>
>> * client makes a connection, no data
>> -> server accepts connection, select() says there is no data
>
> On Mac OS X, poll is used and blocks until data is present (server.c, line 695).  If however I force the use of select, the application hangs on select (server.c, line 726).
>
>
>> * cilent makes a connection, sends data
>> -> server accepts connection, select() says there is data, call read()
>>
>> What is happening in your program that is not one of these two cases?
>> Somehow read() is getting called when there is no data, even though
>> read() is only called after select() says there is data, so there must
>> be some very subtle thing going on here.
>
> This time read is not called, which is fine.
>
>
>> Question: what does your client code look like? The only thing I still
>> find confusing is that you say, "the server tries to read data just
>> after the socket is accepted, even though there is no data to read
>> yet."  However, afaik there is no way for liblo client to make a
>> connection to a server without sending a message, so there should
>> always be a packet of data to read after accept().  Maybe another OSC
>> clients may behave differently though..
>
> The client code is a TCP client written in Cocoa with the VVOSC library, but only the encoding functions are used.  The networking code is handled by a NSSocket, which is basically a wrapper around unix sockets.  I understand that using liblo would not cause this problem to happen, but here the code is used in another developer's application, which makes me believe the problem is legitimate.
>
>
> Cam
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel