[Top][All Lists]
[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
- Re: [Gnumed-devel] GnuMed EMR browser, (continued)