On Sat, 2009-07-11 at 02:06 +0200, 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. >
I've never been a big user of multi-threading, so I can't really comment on types of threads and how they'll be affected, but I'll try and explain what's going on. It sounds like you're using svn, which is good, because I've been trying to make it a bit more consistent. If I've failed, please tell me :) > 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. > I like the idea, and it would in many ways be simpler to use and more robust. The current interface is obviously modelled on the MS interface, and it looks like MS never considered multiple devices in any way. So I don't know which way is best for this, an interface consistent with MS or a better one ? > 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. > Firstly, don't use the context directly, just store and select the connection, it'll be easier. I'm assuming this is where the threading comes in. The only time you'll have a problem with threading is if you pass the same connection into two different threads, in which case you'll need mutexes because the threads might use the socket at the same time. But you'd have the same problem passing the context directly in two different threads as well. Note you should be able to use two different connections to the same device in different threads, because they use separate buffers and sockets. How this works with green threads I have no idea. > 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? > Yes, just ref it. The reference system was based on the use of the rapi_connection_ functions. If you're only using one connection, ie just calling CeRapiInit and uninit, init creates a context and makes it the current, which refs it, and uninit unrefs it, which destroys it. If you create a connection, it creates a context and refs it. When the context becomes the current it gets ref'd, and unref'd when it is no longer the current, but it still has the initial ref from the connection, so is not destroyed. > 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? > If you can use the native threading then you should be able to do this quite easily, otherwise you've got some work to do. If a change in the API along these lines was to go into trunk, in my opinion it should actually be the other way around which would be much more work. Let me explain that last point. Ideally the core API should be changed so the context is passed in as the first parameter, in typical OO style. The MS based API with no context should then be a wrapper around the better API, with the wrapper getting the current context as it does now and passing it into the new API. Make sense ? Of course that involves rewriting a lot of the library :) I hope I've been helpful. Mark
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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
