I have implemented piping between 2 threads of the same process. It is
working the way described below but I would like to see if there is a better
way to do it.

I have the following pipe buffer shared between threads.

struct PipeBuf
{
char* pBuf;
unsigned int len;
};
Here len = 0 indicates the end of input for the reader side.

I create two event objects (I call them read and write event) to synchronise
the threads.
I will use R for reader side and W for writer side. The events objects are
initialized as non-signaled and automatically set to non-signaled when the
thread waiting on them is released right after they are set to signaled by
the other thread.

The following happens:
1 - R starts waiting on write event.
2 - W sets the pipe buffer members and sets the write event and starts
waiting on the read event. R wakes up and processes the pipe data and sets
the read event and starts waiting on the write event again if the pipe
buffer length is not zero.
3 - W wakes up and repeat the step 2 if it has more data to pipe, otherwise
W sets the pipe buffer length to zero and sets the write event to terminate
the R.

My restiction is that the pipe buffer definition should not be altered. That
way it avoids using an intermediary buffer. I mean W may call a library
function to fill it and R also may call a library function to use it. The
buffer pointed to by the pointer (pBuf member) can be set to anything by W.
A pointer to PipeBuffer instance is shared between W and R. So when W sets
pBuf and len members and signals the write event, it is ready to be used by
R right away.

Now my question: Can this be done some other (better) way? Any suggestion?

Aslan wrote:
) I have implemented piping between 2 threads of the same process. It is
) working the way described below but I would like to see if there is a better
) way to do it.
)
) I have the following pipe buffer shared between threads.
)
) struct PipeBuf
) {
) char* pBuf;
) unsigned int len;
) };
) Here len = 0 indicates the end of input for the reader side.
)
) I create two event objects (I call them read and write event) to synchronise
) the threads.
) I will use R for reader side and W for writer side. The events objects are
) initialized as non-signaled and automatically set to non-signaled when the
) thread waiting on them is released right after they are set to signaled by
) the other thread.
)
) The following happens:
) 1 - R starts waiting on write event.
) 2 - W sets the pipe buffer members and sets the write event and starts
) waiting on the read event. R wakes up and processes the pipe data and sets
) the read event and starts waiting on the write event again if the pipe
) buffer length is not zero.
) 3 - W wakes up and repeat the step 2 if it has more data to pipe, otherwise
) W sets the pipe buffer length to zero and sets the write event to terminate
) the R.
)
) My restiction is that the pipe buffer definition should not be altered. That
) way it avoids using an intermediary buffer. I mean W may call a library
) function to fill it and R also may call a library function to use it. The
) buffer pointed to by the pointer (pBuf member) can be set to anything by W.
) A pointer to PipeBuffer instance is shared between W and R. So when W sets
) pBuf and len members and signals the write event, it is ready to be used by
) R right away.
)
) Now my question: Can this be done some other (better) way? Any suggestion?

I think so. Use a (small) ringbuffer of buffer pointers.

That way, W can go on with its business instead of having to wait on R.
If you don't make the ringbuffer too large, then W won't get too far
ahead of R, and won't have too much memory allocated.

Restriction: All buffer pointersshould be from malloc() calls, so that R
can free them. Alternatively, you could add a destructor function pointer
to the struct so that R can call that to clean up.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

"Willem" <willem@stack.nl>, haber iletisinde þunlarý
yazdý:slrnd0c8mn.25ic.willem@toad.stack.nl...

calls W. So R doesn't bother releasing it. Still I can use a buffer of that
size (or ~64K) and use, say, 2 or 4 (8/16?) pointers to partition it.

"Aslan Kral" <aslanski2002@yahoo.com> wrote in
news:36mht8F51qjm9U1@individual.net:

You might want to read an article I wrote that deals with some of
your issues at:
http://home.att.net/~jimmaureenroger..._Patterns.html

Jim Rogers