[Sorry for dupes of this.] Hi,
First of all, it's wonderful to hear that you make good use of SynCE. I would really appreciate if you are able share some more about the context you use SynCE in, either to the list or privately. (It's great to see one's kids grow up I think that you should model the new RAPI interface after the Microsoft RAPI2 Interface (IRAPIDevice, IRAPISession, etc): http://msdn.microsoft.com/en-us/library/aa922133.aspx MS buils these interfaces on top of the Component Object Model (COM) so C++ would be a natural fit, but if you implement it in C for easier Ruby bindings that's fine. Just add "this" (or "self" :-) as first parameter. (I would have implemented the original librapi2 in C++ if it wasn't because I hoped that language bindings would be easier with a C interface.) In the C interface I suggest that you do like this, or something close that makes it easy for the Ruby bindings: HRESULT RAPIDevice_CreateSession( RAPIDevice* self; RAPISession** ppISession ); BOOL RAPISession_CeCopyFile( RAPISession* self, LPCWSTR lpExistingFileName, LPCWSTR lpNewFileName, BOOL bFailIfExists ); Locking (per session) should really be done inside the RAPI calls, not outside. Reference counting could be implemented just like AddRef and Release from IUnknown in COM... :-) Best regards, David Eriksson, http://www.divideandconquer.se/ On Fri, 2009-07-10 at 17:06 -0700, David Richardson wrote: > I'm using librapi for some really cool testing framework stuff at > Flexilis. I'm really trying to push the limits of the library. I've > wrapped librapi in ruby using Ruby::DL but currently I have to mutex > on any RAPI call. I'd really like to only have to mutex per-device. > Ruby only uses green threads so the existing thread safe stuff isn't > going to help me, I believe. I want to run tests on hundreds of > devices in parallel. > > What I want to do is create alternative wrappers for each RAPI > function where I pass the context in as the last parameter, rather > than specifying it ahead of time with . I tried some initial > experimentation with this yesterday, but didn't have much luck. > Before I dive too deep into it, I wanted to make my proposal and hear > any comments you have. Specifically I'm concerned about how the > contexts work and when/how they become invalidated. > > Serially I will create each connection (rapi_connection_from_name), > select it (rapi_connection_select), initialize it (CeRapiInit) and > store the current context (get_current_context). Then in parallel I > will call modified RAPI functions on hundreds of devices that take the > context in as a paramater. > > I notice that the act of selecting a connection unref's the previously > selected connection and destroys it (since this was the only > reference). Is it sufficient for me to just store a reference to each > context and call rapi_context_ref (and unref when I'm done)? Is there > anything else that would invalidate the previous context? > > I'll hopefully be experimenting with this sometime next week. Is this > a change that others would be interested in contributing toward > librapi's trunk? Do you have a suggestion of a better way to go > about this? Is there maybe some existing functionality that I'm > missing that already allows this? > > Thanks! > -David Richardson > Flexilis Mobile Security ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
