[nanomsg] Re: [PATCH] Terminate astream if initializing usock failed
- From: Nir Soffer <nirsof@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 13 Mar 2013 10:53:08 +0200
On Wed, Mar 13, 2013 at 10:31 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> Hi Nir,
>
>
> Yes. But why not do it this way:
>>>
>>> rc = setsockopt (...);
>>> #ifdef NN_HAVE_OSX
>>> /* Due to bug on OSX, EINVAL may mean that the peer has disconnected.
>>> Ignore it and assume send/recv functions will report the error later
>>> on. */
>>> errno_assert (rc == 0 || errno == EINVAL);
>>> #else
>>> errno_assert (rc == 0);
>>> #endif
>>>
>>> That way we don't have to change prototype of nn_uscok_tune() function
>>> just because there's a bug in OSX.
>>>
>>> Generally speaking, I would like to have code dealing with platform bugs
>>> and deficiencies to have as little scope as possible.
>>>
>>
>>
>> We can do this - but you have to repeat this for all setsockopt calls and
>> for fnctl call. And It may cause trouble later in nn_stream_init if the
>> socket is blocking.
>>
>> Changing nn_sock_tune to return an error is good anway - it is eaiser to
>> change error handling later if needed.
>>
>
> You are right in that usock_tune() may return error. For example, if
> there's no sufficient memory for socket buffers it may return with ENOMEM
> or ENOBUFS.
>
> That being the case, I've applied you patch and tried to fix the
> termination mechanism (in the case when usock_tune() returns error). I've
> immediately run into a little twisted maze of callbacks and strange corner
> cases.
>
> Thus, I propose the following solution: At the moment I'll let
> usock_tune() ignore the EINVAL error from setsockopts on OSX platform. That
> should solve the problem of assertions. I'll put a big TODO there stating
> that the error should rather be passed to the caller instead of ignoring it.
>
> Then we implement proper mechanism for handling asynchronous events (queue
> of events instead of callbacks).
>
> Once done, we can re-write usock_tune() to actually return the error and
> handle it in astream/cstream classes.
>
> Does the plan work for you?
Anything that make some progress works for me :-) Lets see how it works.
Do you have a short tem solution for the harder (callback maze) issue?
Other related posts:
