[nanomsg] Re: [PATCH] Terminate astream if initializing usock failed

  • From: Nir Soffer <nirsof@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Tue, 12 Mar 2013 16:10:29 +0200

On Tue, Mar 12, 2013 at 3:47 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:

> Hi Nir,
>
>
>  The problem is the the callback which calls you back when you do not
>> expect
>> it:
>>
>> obj_do_this (object)
>>     deeper (object)
>>         even_deeper (object)
>>             // something failed here
>>             obj_error_callback (object)
>>                 obj_term (object)
>>                     free (object)
>> obj_do_that (object) -- crash - now if you are lucky, or later if not.
>>
>> Lets assume that obj_do_this() should invoke the error callback, since it
>> is called from some other event, so we cannot return an error code.
>>
>> We can do is:
>>
>> obj_do_this (object)
>>     deeper (object)
>>         even_deeper (object)
>>             // something failed here
>>             mark object as invalid
>>             send event that will run obj_error_callback later
>> obj_do_that (object)
>>     return error if object is invalid
>>
>> In the next event loop iteration:
>>
>> obj_error_callback (object)
>>     terminate and free object
>>
>> A simpler solution would be to always return an error code, so if a
>> function failed and terminated the object, the next function can detect
>> it.
>>
>
> My proposition was to handle this situation using mailboxes (similar to
> how Erlang, or other message driven languages/platforms work):
>
>
> obj_do_this (object)
>     deeper (object)
>         even_deeper (object)
>             // something failed here
>             send_message (object, ERROR_MESSAGE)
> process_pending_messages (object)
>     process_message (object, ERROR_MESSAGE)
> //  at this point object is cleaned up so it cannot be called with
> obj_do_that function
>
> It's basically similar to flagging the object, except that instead of a
> single flag you have a queue of messages to be processed later on.


I don't know if mailboxes per object are needed, a single queue in the
event loop may be enough.

The main idea is that object is never deallocated in the middle of an
event, so you can access it after failures.

Other related posts: