gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] GnuMed EMR browser


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] GnuMed EMR browser
Date: Fri, 13 Aug 2004 10:31:17 +0200
User-agent: Mutt/1.3.22.1i

> > Well, the other option would be to eventually write the async
> > fetcher.
> I have looked into this, I can't see an easy solution.
> wxSockets (which generate events when data comes in off the network) aren't 
> bound
> in wxPython, as a matter of policy.
IMO you are thinking lower-level than necessary here.

> EVT_IDLE is too slow as Karsten has said.
> Apparently Python has it's own mechanism for asynchronously listening for 
> network traffic,
> (which is why Robert Dunn refuses to write bindings for wxPython) but I don't 
> understand
> how this is meant to interact with the wxWindows event loop.
> 
> In any case, none of these work with the existing postgres libraries, which, 
> AFAICT, are
> firmly synchronous, so we are back to rolling our own. 

I think the rub lies in realizing that we likely don't require
a true *async* fetcher at all but rather one that runs as a
Python thread and mostly does its work while nothing is
happening - eg. prefetching when the user is (still) idlging.

I am really more concerned with exactly how (and it needs to
be KISS so we [I] can be sure of its reliability) to
lock/sync/notify between the worker thread and the user(s), eg
making the API "thread-safe". The itch on this is getting
stronger so I might actually attempt this within the next few
months/weeks.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]