|
Home > Archive > Unix Programming > July 2004 > pipe of size 1
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Tejas Kokje 2004-07-24, 2:48 am |
| Hello,
How to make pipe of size 1. I mean what I want is writer
always write one value. Whenever writer wants to write another,
it over writes the old value in pipe.
Reader always reads one value.
How can i implement them using UNIX pipes
Tejas Kokje
| |
| Lev Walkin 2004-07-24, 2:48 am |
| Tejas Kokje wrote:
> Hello,
>
> How to make pipe of size 1. I mean what I want is writer
> always write one value. Whenever writer wants to write another,
> it over writes the old value in pipe.
>
> Reader always reads one value.
>
> How can i implement them using UNIX pipes
....by switching to using the shared memory.
--
Lev Walkin
vlm@lionet.info
| |
| Michael B Allen 2004-07-24, 2:48 am |
| On Sat, 24 Jul 2004 00:08:26 -0400, Lev Walkin wrote:
>
> ...by switching to using the shared memory.
How does shared memory allow you to make a UNIX pipe with a buffer size
of only 1?
Mike
| |
| Lev Walkin 2004-07-24, 2:48 am |
| Michael B Allen wrote:
> On Sat, 24 Jul 2004 00:08:26 -0400, Lev Walkin wrote:
>
>
>
>
> How does shared memory allow you to make a UNIX pipe with a buffer size
> of only 1?
By creating a cognitive leap in your head forcing you to use the appropriate
tools for the task.
--
Lev Walkin
vlm@lionet.info
| |
| Tejas Kokje 2004-07-28, 6:19 pm |
| Actually the platform on which I am working doesn't seem to
have shared memory support.(Even simple shared memory programs
didn't run :-( ). I am working on Linksys WRT54GS router
which runs Linux.
Regards,
Tejas Kokje
On Sat, 24 Jul 2004 01:18:17 -0700, Lev Walkin wrote:
> Michael B Allen wrote:
>
> By creating a cognitive leap in your head forcing you to use the appropriate
> tools for the task.
| |
| Michael B Allen 2004-07-28, 6:19 pm |
| On Sat, 24 Jul 2004 04:18:17 -0400, Lev Walkin wrote:
>
> By creating a cognitive leap in your head forcing you to use the
> appropriate tools for the task.
Ahh, based on this and your other posts I see clearly now. I haven't
been around in a while. I guess everyone else has already reached the
point where they know to just ignore you.
| |
| Lev Walkin 2004-07-28, 6:19 pm |
| Tejas Kokje wrote:
> Actually the platform on which I am working doesn't seem to
> have shared memory support.(Even simple shared memory programs
> didn't run :-( ). I am working on Linksys WRT54GS router
> which runs Linux.
Okay, here's the problem: you want the receiver to fetch only
the last status value from another process.
You cannot do it using pipes, because the pipes interface is not
designed to handle such case. And you cannot do it using shared
memory support, because your hardware has a Linux which is
compiled without SysV IPC support enabled.
You could do the following:
1. Recompile the Linux, or somehow else obtain a kernel with
System V IPC services enabled. This would be the easiest from
a programming standpoint: shared memory support is quite easy
to implement.
2. If the first one is not an option, there is the trick:
open a file descriptor (literally, a descriptor of a file), and
delete the file. Then lock it using write lock (lockf, flock
or fcntl(2) interfaces). Provide a client (child?) with the
copy of this descriptor (dup() or another open() of the file
before it is being deleted). Let it try to lock the file
too. Then, if you need to communicate status, simply write
something in the beginning of the file (pwrite(2) or
fseek() + write()). Make sure the size is small enough to
guarantee atomicity. After writing, unlock the file and lock
it again.
Meanwhile, the client will obtain the lock on the file during
the window between the sender unlocks the file and locks it
again. While holding a lock, client should read the first N (1?)
bytes of the file using pread() or fseek()+pread(), and then
unlock the file and try to lock it again.
This should solve the task of supplying the status to your
client. The locks aren't doing anything to "synchronize"
this atomic process: they are needed only to communicate
that the new data is available in that file.
3. Use signals: if you need to communicate a status, you
typically don't have to supply the whole 1b value to the
receiver: it is often enough to have a handful of status
codes. Use different signals (like, SIGUSR1 and SIGUSR2)
to communicate different status codes.
P.S. I am assuming you need to communicate status codes
between two applications or an instances of one application,
or something like that. If what you really need is just to
use pipe() + have a way to overwrite 1 byte, please talk to
Michael B Allen, which certainly has more solid experience
answering precisely the question which was asked.
[vbcol=seagreen]
> On Sat, 24 Jul 2004 01:18:17 -0700, Lev Walkin wrote:
>
--
Lev Walkin
vlm@lionet.info
| |
| Chuck Dillon 2004-07-28, 6:19 pm |
| Tejas Kokje wrote:
> Hello,
>
> How to make pipe of size 1. I mean what I want is writer
> always write one value. Whenever writer wants to write another,
> it over writes the old value in pipe.
>
> Reader always reads one value.
>
> How can i implement them using UNIX pipes
>
> Tejas Kokje
An alternative to using shared memory would be to use a semaphore
(assume they are enabled) as a mailbox.
-- ced
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
| |
| Lev Walkin 2004-07-28, 6:19 pm |
| Chuck Dillon wrote:
> Tejas Kokje wrote:
>
>
>
> An alternative to using shared memory would be to use a semaphore
> (assume they are enabled) as a mailbox.
1. time-bound waiting on semaphores is not portable.
2. there is no simple mechanism to wait on socket/pipe events
and semaphore status changes at the same time. (except using
threads or forking off processes and then supplying semaphore
conditions back using [drum...] the pipe again).
--
Lev Walkin
vlm@lionet.info
| |
| Chuck Dillon 2004-07-28, 6:19 pm |
| Lev Walkin wrote:
> Chuck Dillon wrote:
>
>
>
> 1. time-bound waiting on semaphores is not portable.
> 2. there is no simple mechanism to wait on socket/pipe events
> and semaphore status changes at the same time. (except using
> threads or forking off processes and then supplying semaphore
> conditions back using [drum...] the pipe again).
>
You've lost me. The OP wants a single byte mailbox shared between
processes. A semaphore can provide such a mechanism without the need
for a time bound wait or a socket/pipe.
-- ced
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
| |
| Lev Walkin 2004-07-28, 6:19 pm |
| Chuck Dillon wrote:
> Lev Walkin wrote:
>
>
> You've lost me. The OP wants a single byte mailbox shared between
> processes. A semaphore can provide such a mechanism without the need
> for a time bound wait or a socket/pipe.
Not lost, just commenting.
Anyway, that box does not have SysV IPC.
--
Lev Walkin
vlm@lionet.info
| |
| SM Ryan 2004-07-28, 6:19 pm |
| # Anyway, that box does not have SysV IPC.
If you have disk files, you shared memory. Everyone opens the same file
and seeks to 0 before writing the same size data. You can use fcntl or
open create exclusive, or mkdir to serialize writers and readers if
you want.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
OOOOOOOOOO! NAVY SEALS!
| |
| Lev Walkin 2004-07-28, 6:19 pm |
| SM Ryan wrote:
> # Anyway, that box does not have SysV IPC.
>
> If you have disk files, you shared memory. Everyone opens the same file
> and seeks to 0 before writing the same size data. You can use fcntl or
> open create exclusive, or mkdir to serialize writers and readers if
> you want.
You aren't following the thread, are you?
http://groups.google.com/groups?q=p...erlin.de&rnum=1
--
Lev Walkin
vlm@lionet.info
|
|
|
|
|