On Thu, Feb 5, 2009 at 1:34 AM, Juan Lang juan.l...@gmail.com wrote:
Hi Luke,
hi juan, thanks for responding.
how about: ripping out the use of unix-pipes altogether, and replacing
them with tdb (trivial database) in a mmap'd file? the nice thing
The usual response around here is, show us
On Thu, Feb 5, 2009 at 4:08 PM, Juan Lang juan.l...@gmail.com wrote:
i think i've finally come up with an idea that i believe will work:
double-socketing.
(snip)
it'll be ok (and desirable) to allow multiple readers of the read
socket. what you _don't_ want is more than one reader trying to
On Thu, Feb 5, 2009 at 6:38 PM, Juan Lang juan.l...@gmail.com wrote:
and no, you _can't_ do everything in wineserver, because you _still_
need a mechanism to be able to tell the client (ntdll) to block.
Well, if there are two fds still, but each end is either a client
(reading or writing) and
i think i've finally come up with an idea that i believe will work:
double-socketing.
(snip)
it'll be ok (and desirable) to allow multiple readers of the read
socket. what you _don't_ want is more than one reader trying to
indicate please start sending a new message whilst there are other
and no, you _can't_ do everything in wineserver, because you _still_
need a mechanism to be able to tell the client (ntdll) to block.
Well, if there are two fds still, but each end is either a client
(reading or writing) and the other is the wineserver, I believe you
could. That is, the server
mwhaaahahah, i just came up with a _horrible_ idea :)
how about: ripping out the use of unix-pipes altogether, and replacing
them with tdb (trivial database) in a mmap'd file? the nice thing
about tdb is that it's LGPL'd. the messages could be saved and
transferred via shared memory; tdb is
ok, alexandre: i tried moving named_pipe_read into wineserver - it's
not possible to do completely, as you cannot do blocking-reads in
wineserver but you still need blocking-read characteristics in the
client (kernel32, ntdll). if you start messing with the fd, setting
or clearing ioctl
