On Sat, 03 Jun 2006 09:43:04 +0200, Alexandre Julliard wrote:
> If it's a solution that can be expanded later on to cover the other
> cases, yes, but not if it's a dead-end.
When this was discussed before the idea of bringing back the service
thread was raised. I still think we should do this, ass
Alexandre Julliard wrote:
"Dan Kegel" <[EMAIL PROTECTED]> writes:
On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
The problem here is that you don't control at what point you interrupt
the process, so you can't do anything in it except system calls, and
that won't be enough.
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> How 'bout we also implement remote thread creation, and create
> a temporary service thread to service a remote memory allocation request?
> That would give the thread context you say is required.
Yes that's a possibility, we need support for creating rem
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> Are you willing to accept a patch which makes some common use
> cases work well, but does not address others?
If it's a solution that can be expanded later on to cover the other
cases, yes, but not if it's a dead-end.
--
Alexandre Julliard
[EMAIL PROTEC
Friday, June 2, 2006, 9:33:30 PM, Dan Kegel wrote:
> On 6/2/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
>> > You need to have a thread waiting one way or another, since you need
>> > to perform operations on the client side that require a thread
>> > context. No, it's not an easy problem to solve, tha
On 6/2/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
> You need to have a thread waiting one way or another, since you need
> to perform operations on the client side that require a thread
> context. No, it's not an easy problem to solve, that's why it has not
> been done yet...
Are you willing to ac
On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> How about this: we combine the original sychronous approach
> with the small preallocated cache as a fallback for when
> no threads are waiting?
You need to have a thread waiting one way or another, since you need
to perform operations o
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> How about this: we combine the original sychronous approach
> with the small preallocated cache as a fallback for when
> no threads are waiting?
You need to have a thread waiting one way or another, since you need
to perform operations on the client side
On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> OK, new plan: how about we preallocate a memory
> area just big enough for the common case, with the
> structures all set up, and let the server hand it
> out to the first process to ask for it? I don't think
> it needs to be very big.
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> OK, new plan: how about we preallocate a memory
> area just big enough for the common case, with the
> structures all set up, and let the server hand it
> out to the first process to ask for it? I don't think
> it needs to be very big.
Well, that may wor
On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Why isn't a call to mmap enough?
You need to build the proper structures on the client side, just like
a normal VirtualAlloc would, otherwise the process won't know about
that memory area.
OK, new plan: how about we preallocate a memor
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
>> The problem here is that you don't control at what point you interrupt
>> the process, so you can't do anything in it except system calls, and
>> that won't be enough.
>
> Why isn't a call to mmap
On 6/2/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
The problem here is that you don't control at what point you interrupt
the process, so you can't do anything in it except system calls, and
that won't be enough.
Why isn't a call to mmap enough?
(We're trying to support techniques like th
[EMAIL PROTECTED] writes:
> I ran across the need to do memory allocations across processes and came upon
> Alexander Yaworsky's patch at
> http://www.winehq.org/pipermail/wine-devel/2004-September/029953.html and took
> a different approach. Instead of waiting for the target process to check a fd
Hello,
I ran across the need to do memory allocations across processes and came upon
Alexander Yaworsky's patch at
http://www.winehq.org/pipermail/wine-devel/2004-September/029953.html and took
a different approach. Instead of waiting for the target process to check a fd,
I changed the implementat
On 6/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
One thought that has recently crossed my mind: Building off his framework and
putting much of the code in the server may not have been a great idea, since
the only real need for the server is to get the unix pid of the thread.
Nah, I think
16 matches
Mail list logo
