You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2014/03/19 20:11:43 UTC

[jira] [Commented] (TS-2651) atscppapi: race conditions in destruction of async providers

    [ https://issues.apache.org/jira/browse/TS-2651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940861#comment-13940861 ] 

ASF GitHub Bot commented on TS-2651:
------------------------------------

GitHub user manjeshnilange opened a pull request:

    https://github.com/apache/trafficserver/pull/64

    atscppapi: fixes for TS-2651: race conditions in destruction of ...

    ...async providers.
    
    Also, I noticed a duplicated lock while invoking an intercept plugin. Though the duplicate lock doesn't do any harm (mutex is recursive), we don't need it.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/manjeshnilange/trafficserver master

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/trafficserver/pull/64.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #64
    
----
commit f979862b39914172caee4408d5733060516e2556
Author: Manjesh Nilange <ma...@yahoo.com>
Date:   2014-03-19T19:07:52Z

    atscppapi: fixes for TS-2651: race conditions in destruction of async providers

----


> atscppapi: race conditions in destruction of async providers
> ------------------------------------------------------------
>
>                 Key: TS-2651
>                 URL: https://issues.apache.org/jira/browse/TS-2651
>             Project: Traffic Server
>          Issue Type: Bug
>            Reporter: Manjesh Nilange
>            Assignee: Brian Geffon
>
> There are two corner cases that I can think of -
> 1) Developer delete()ing AsyncHttpFetch before fetch is complete. 
> In the .h documentation, we say that the fetch object will delete itself, so the implication is that developer need not delete it. However, we don't make sure that developer can't. Because if they do it (by mistake) before the fetch is complete, the fetch object's state is deleted, and then when the fetch actually completes, there will be chaos. 
> 2) Developer delete()ing AsyncTimer exactly at the time a timing event happens. 
> AsyncTimer requires the developer to delete the timer explicitly (with a periodic timer, we can't do self-destruction). If developer's delete happens at the same time as a event on the continuation, then we will have problems as the destructor tries to destroy the continuation that is being invoked in another thread. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)