Re: [liblo] lo_server_recv_wait

On Tue, Dec 23, 2008 at 2:23 PM, Nicholas J Humfrey <nj...@ae...> wrote:
>
> On 23 Dec 2008, at 19:17, Stephen Sinclair wrote:
>
>> On Sat, Dec 20, 2008 at 7:26 PM, Nicholas J Humfrey <nj...@ae...>
>> wrote:
>>> Hello,
>>>
>>> I would like to propose adding a new method to the liblo API called
>>> lo_server_recv_wait.
>>>
>>> Its implementation would be almost exactly the same as
>>> lo_server_recv_noblock, except it just waits for some data to be
>>> ready
>>> for processing and does not call lo_server_recv itself. It would
>>> return 1 if there is a message waiting or 0 if it timed out.
>>>
>>> The reason for this is because I am trying to implement OSC support
>>> in
>>> VLC, but I am having issues with VLC's thread cancelling. VLC creates
>>> the thread itself and I am using liblo's low level lo_server
>>> functions. Basically I want the thread to be cancellable while
>>> waiting
>>> for a message (while lo_server_recv_wait is blocking). But while the
>>> message is being processed (and handlers are being called). I don't
>>> want the thread to be cancellable.
>>>
>>> I don't believe there is a way of doing this at the moment because
>>> waiting for a message and processing that message are the same API
>>> call...
>>
>> Couldn't it be done by using lo_server_get_socket_fd() and calling
>> select() on it?
>>
>> This doesn't mean I'm opposed to adding lo_server_wait(), but it seems
>> like that's essentially what it would do.
>
> It is theoretically that simple but if you look at the code for
> lo_server_recv_noblock(), it has the two different implementations for
> Windows and Unix and also checks for scheduled events too.
>
> Seems sensible to separate out that functionality into a reusable
> function.

Right, particularly checking for scheduled events is something that
couldn't be done without liblo's support, that's a good point.

Steve