[jira] Commented: (THRIFT-491) Ripping raw pthreads out of TFileTransport and associated test issues

["Rush Manbert (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707187#action_12707187 ] 

Rush Manbert commented on THRIFT-491:
-------------------------------------

Rather than defining a new Condition class, it turns out to make a lot more sense to just add this public method to Monitor:
  /** Create a new Monitor that has a different condition, but shares the mutex with this one.
   */
  shared_ptr<Monitor> newMonitorSharedMutex() const;

and change the implementation to keep a boost::shared_ptr to the mutex object. This allows three Monitor objects to be used in TFileTransport in place of the three pthread_cond_t objects that it has now.

It looks like I need to define a new class that just does basic threading, either pthreads or boost threads. That will take care of the writer thread.

Comments?


> Ripping raw pthreads out of TFileTransport and associated test issues
> ---------------------------------------------------------------------
>
>                 Key: THRIFT-491
>                 URL: https://issues.apache.org/jira/browse/THRIFT-491
>             Project: Thrift
>          Issue Type: Question
>          Components: Library (C++)
>    Affects Versions: 0.1
>         Environment: Mac OS X 10.5.6
>            Reporter: Rush Manbert
>
> The last piece of replacing the pthread-based threading implementation with a Boost threads implementation is to replace all of the raw ptherad mutex and condition usage in TFileTransport.
> I think the best way to proceed is to define a Condition class, similar to the way there is a Mutex class defined, give it a generic API that satisfies the demands of TFileTransport, then implement it both ways. You would need to construct a Condition object with a Mutex object reference, or probably a weak_ptr<Mutex> so we can know that the condition waits are safe. I'll add a comment with the API I work out.
> However, my main concern is how to test the new code. It looks like I can use stress-test, but iI was hoping that someone who is familiar with the app could give me some pointers or a test procedure that exercises the threading code.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.