Mel wrote:
> Philip Semanchuk wrote:
>
>> I'm working on message queue support, but the Sys V IPC API is a
>> headache and takes longer to code against than the POSIX API.
>
> I hadn't found it that bad. I have a C extension I should perhaps clean
> up and make public.
I have a simple wrapper
On Jan 14, 12:47 pm, Laszlo Nagy wrote:
> multiprocessing.Queue cannot be used as a general message queue
> between arbitrary processes.
Then e.g. use Listener and Client in multiprocessing.connection to
create a named pipe (AF_PIPE). Or use win32pipe.CreateNamedPipe from
pywin32.
> - mmap.mma
There are plenty of different IPC mechanisms available in
multiprocessing.
It is good for a special case: a tree of processes, forked from a main
process. multiprocessing.Queue cannot be used as a general message queue
between arbitrary processes.
- mmap.mmap with 0 or -1 as the first argu
On Jan 13, 5:25 pm, Laszlo Nagy wrote:
> I would like to develop some module for Python for IPC. Socket
> programming howto recommends that for local communication, and I
> personally experienced problems with TCP (see my previous post: "Slow
> network").
There are plenty of different IPC mechan
On Jan 13, 2009, at 11:26 PM, drobi...@gmail.com wrote:
On Jan 13, 5:08 pm, Philip Semanchuk wrote:
On Jan 13, 2009, at 4:31 PM, drobi...@gmail.com wrote:
On Jan 13, 2:37 pm, Philip Semanchuk wrote:
I was suggesting getting posix_ipc or sysv_ipc to compile against a
compatibility library
On Jan 13, 5:08 pm, Philip Semanchuk wrote:
> On Jan 13, 2009, at 4:31 PM, drobi...@gmail.com wrote:
>
> > On Jan 13, 2:37 pm, Philip Semanchuk wrote:
> >> I was suggesting getting posix_ipc or sysv_ipc to compile against a
> >> compatibility library (Cygwin?) under Windows. It sounds like you're
On Jan 13, 2009, at 6:41 PM, Mel wrote:
Philip Semanchuk wrote:
I'm working on message queue support, but the Sys V IPC API is a
headache and takes longer to code against than the POSIX API.
I hadn't found it that bad. I have a C extension I should perhaps
clean up
and make public.
Ha
On Wed, Jan 14, 2009 at 3:40 AM, Laszlo Nagy wrote:
> Can anyone tell me if select.select works under OS X?
Yes it does.
cheers
James
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, Jan 14, 2009 at 2:25 AM, Laszlo Nagy wrote:
> The question is: what is the standard way to implement fast and portable IPC
> with Python? Are there tools in the standard lib that can do this?
Certainly not standard by any means, but I use
circuits (1). Two or more processes can communicat
Laszlo Nagy wrote:
I was suggesting getting posix_ipc or sysv_ipc to compile against a
compatibility library (Cygwin?) under Windows. It sounds like you're
proposing something totally different, no?
OK I see. But probably I do not want to use Cygwin because that would
create another depende
Philip Semanchuk wrote:
> I'm working on message queue support, but the Sys V IPC API is a
> headache and takes longer to code against than the POSIX API.
I hadn't found it that bad. I have a C extension I should perhaps clean up
and make public.
Mel.
--
http://mail.python.org/mailman/
On Jan 13, 2009, at 4:31 PM, drobi...@gmail.com wrote:
On Jan 13, 2:37 pm, Philip Semanchuk wrote:
I was suggesting getting posix_ipc or sysv_ipc to compile against a
compatibility library (Cygwin?) under Windows. It sounds like you're
proposing something totally different, no?
It's not rea
On Jan 13, 2009, at 3:04 PM, Laszlo Nagy wrote:
I was suggesting getting posix_ipc or sysv_ipc to compile against a
compatibility library (Cygwin?) under Windows. It sounds like
you're proposing something totally different, no?
OK I see. But probably I do not want to use Cygwin because t
On Jan 13, 2:04 pm, Laszlo Nagy wrote:
> - create a wrapper, using ctypes, /windll / cdll/ to access API functions
> - use CreateFileMapping on the page file to create shared memory (a la
> windows:http://msdn.microsoft.com/en-us/library/aa366537.aspx)
> - use CreateEvent/WaitForSingleObject for s
On Jan 13, 2:37 pm, Philip Semanchuk wrote:
> On Jan 13, 2009, at 2:01 PM, Laszlo Nagy wrote:
>
>
>
> >> I realize that lack of Windows support is a big minus for both of
> >> these modules. As I said, any help getting either posix_ipc or
> >> sysv_ipc working under Windows would be much appre
I was suggesting getting posix_ipc or sysv_ipc to compile against a
compatibility library (Cygwin?) under Windows. It sounds like you're
proposing something totally different, no?
OK I see. But probably I do not want to use Cygwin because that would
create another dependency. I understand th
On Jan 13, 2009, at 2:01 PM, Laszlo Nagy wrote:
I realize that lack of Windows support is a big minus for both of
these modules. As I said, any help getting either posix_ipc or
sysv_ipc working under Windows would be much appreciated. It sounds
like you have access to the platform and
I realize that lack of Windows support is a big minus for both of
these modules. As I said, any help getting either posix_ipc or
sysv_ipc working under Windows would be much appreciated. It sounds
like you have access to the platform and incentive to see it working,
so dig in if you like.
M
On Jan 13, 2009, at 1:22 PM, Laszlo Nagy wrote:
- posix_ipc is broken under FreeBSD
A clarification: the module posix_ipc is *not* broken. It exposes
FreeBSD's implementation of POSIX IPC which has broken semaphores
(based on my experiments, anyway). The practical result for you is
t
- posix_ipc is broken under FreeBSD
A clarification: the module posix_ipc is *not* broken. It exposes
FreeBSD's implementation of POSIX IPC which has broken semaphores
(based on my experiments, anyway). The practical result for you is the
same but the difference is very important to me as
On Jan 13, 2009, at 12:40 PM, Laszlo Nagy wrote:
The only reason to use shm over the sysv_ipc module is that shm
supports versions of Python < 2.5. I'm not developing shm any
further, so avoid using it if possible.
Hmm, we are using FreeBSD, Ubuntu and Windows. Unfortunately
- posix_ipc
I use Pyro. Has always been fast enough for me. It spares you the troubles
of bloated XML-documents other RPC-mechanisms use.
Of course it is RPC, not "only" IPC - so it comes with a tradeoff. But so
far, it has been always fast enough for me.
Unfortunately, I'm developing an ORB, and using
The only reason to use shm over the sysv_ipc module is that shm
supports versions of Python < 2.5. I'm not developing shm any further,
so avoid using it if possible.
Hmm, we are using FreeBSD, Ubuntu and Windows. Unfortunately
- posix_ipc is broken under FreeBSD
- sysv_ipc does not support me
Laszlo Nagy wrote:
> I would like to develop some module for Python for IPC. Socket
> programming howto recommends that for local communication, and I
> personally experienced problems with TCP (see my previous post: "Slow
> network").
>
> I was looking for semaphores and shared memory, but it is
On Jan 13, 2009, at 11:25 AM, Laszlo Nagy wrote:
I would like to develop some module for Python for IPC. Socket
programming howto recommends that for local communication, and I
personally experienced problems with TCP (see my previous post:
"Slow network").
I was looking for semaphores a
I would like to develop some module for Python for IPC. Socket
programming howto recommends that for local communication, and I
personally experienced problems with TCP (see my previous post: "Slow
network").
I was looking for semaphores and shared memory, but it is not in the
standard lib. I
26 matches
Mail list logo
