Re: [Pyobjc-dev] Receiving distributed notifications in different thread

[Gerard T. <gto...@gm...>]

Hi Robert,

It looks like what we're trying to achieve in the way envisioned isn't the
most reliable way of doing things. We've tried to do this through
distributed objects instead, which have the advantage that the run loop is
no longer involved. That does work, which is good, but
we're probably going to merge the separate daemon process into the web
server as a library and run it from a separate thread,
so that it all becomes one process instead. The complexity that we wanted
to avoid there is to write a wrapper around the library so
it becomes available from a python perspective.

Thanks for your help!

G>


On Mon, Oct 6, 2014 at 5:26 PM, Robert Klep <rob...@gm...> wrote:

> I'm not very familiar with Mach ports, but I can reproduce the problem.
>
> It seems to be rather specific to Mach ports, because it works better (in
> that it doesn't hang in the call to NSRunLoop.addPort_forMode_() anymore)
> using an NSSocketPort.
>
> NSMachPort.scheduleForRunLoop_forMode_(), interestingly, throws a SIGSEGV.
>
> Anyway, I really can't provide you with more help at this point :)
>
> – robert
>
> Gerard Toonstra <gto...@gm...> wrote on Mon Oct 06 2014 at
> 20:13:30:
>
> Hi Robert,
>
> Not a problem at all, I'm always open to suggestions. We do actually have
> a redis server running, but that's to communicate regional or global events
> from a number of servers. Also, the project doesn't mandate that that redis
> process is running, so it's not critical in the system. It's only used to
> give the system overall a slightly more realtime nature.
>
> In this case, the webserver always runs on the same machine where the
> hardware events are occurring. For that reason, I was looking for a more
> direct way of communicating
> to the webserver without creating this dependency on redis. However, I'm
> not sure if I can get the proxy to work that way because of the way how
> threads and runloops of osx work.
>
> So I tried to implement what's going on here:
>
>
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Notifications/Articles/Threading.html
>
> In the 'setUpThreadingSupport" function, it hangs on the
>
>   [[NSRunLoop currentRunLoop] addPort:self.notificationPort
>
>  forMode:(NSString __bridge *)kCFRunLoopCommonModes];
>   call and CPU goes to 100%. The "self" object is an NSObject.
>
> My assumption is that I am looking at the right way to enable threaded
> reception of distributed notifications and handle them in that code.
> The main thread of the webserver is controlled by django and doesn't
> eventually call the "control loop", which could be another reason this
> doesn't work well.
>
> Is this something that ought to work anyway, or would you recommend, given
> the rest of the architecture, to do this another way?
>
> Rgds,
>
> Gerard
>
>
> On Mon, Oct 6, 2014 at 2:18 PM, Robert Klep <rob...@gm...> wrote:
>
>> Hoi Gerard,
>>
>> I certainly don't want to berate your project, but just wondering:
>> wouldn't it be much easier to use something like Redis (or a full-blown MQ
>> broker) to distribute notifications?
>>
>> – robert
>>
>> Gerard Toonstra <gto...@gm...> wrote on Mon Oct 06 2014 at
>> 18:08:47:
>> > Hello,
>> >
>> > I'm new to pyobjc. We're using it for a project to receive events from
>> a command line tool in C which interfaces to drivers to generate events on
>> hardware changes.
>> >
>> > There's another process coded in 100% python where we want to receive
>> such notifications and use them. Unfortunately, we haven't had much luck so
>> far. This 100% python process is a webserver, specifically django. In the
>> startup code, we want to create a class (singleton) that creates a separate
>> thread to deal with these distributed notifications.
>> >
>> > For a small test script as a proof of concept, the runConsoleEventLoop
>> is called from the main thread and everything works. Apparently because
>> each thread has or should have its own input sources and the main thread is
>> responsible for those. Creating a new thread requires the programmer to add
>> their own. Not doing that, the loop immediately returns as the "nextfire"
>> variable will be "None".
>> >
>> > We've been struggling to add our own input source, specifically one
>> that deals with distributed notifications, to this runloop. When we call
>> the following code:
>> >
>> >         self.notifications = NSMutableArray.alloc().init()
>> >         self.notiticationLock = NSLock.alloc().init()
>> >         self.notificationThread = NSThread.currentThread()
>> >
>> >         self.notificationPort = NSMachPort.alloc().init()
>> >         self.notificationPort.setDelegate_(self)
>> >         runLoop = NSRunLoop.currentRunLoop()
>> >         runLoop.addPort_forMode_( self.notificationPort,
>> kCFRunLoopCommonModes )
>> >
>> > It hangs on the last line "addPort_forMode_" and so we never get to the
>> loop section.  I think that's a bug, because the same code is used by an
>> example from Apple, where they'd call run() or some other equivalent to
>> start processing those events in the run loop.
>> >
>> > What are we doing wrong?  does anyone know an example that demonstrates
>> this?
>> >
>>
>>
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>