Can you elaborate on this rather odd statement? POSIX threads and
file descriptor (or even stdio) I/O interfaces work just fine together.
There's always the poll and select family of system calls to provide timeouts; I use poll extensively in threaded networking code.
Scott Lurndal, dans le message <OZELH.2391$ew6.163@fx11.iad>, a écrit :
Can you elaborate on this rather odd statement? POSIX threads and
file descriptor (or even stdio) I/O interfaces work just fine together.
Oh? Then please tell me: how do you multiplex a mutex or condition wait with a socket accept?
Scott Lurndal, dans le message <OZELH.2391$ew6.163@fx11.iad>, a écrit :
Can you elaborate on this rather odd statement? POSIX threads and
file descriptor (or even stdio) I/O interfaces work just fine together.
Oh? Then please tell me: how do you multiplex a mutex or condition wait with >a socket accept?
There's always the poll and select family of system calls to provide
timeouts; I use poll extensively in threaded networking code.
That's exactly what I mean: you have threads, and you still need to use I/O >multiplexing.
No, you don't _need_ to use I/O multiplexing in most cases (e.g. disk files).
For socket endpoints, I'll create a pipe(2) to use to notify the thread to exist and the thread main loop will poll the pipe and the socket fd. The main code will write a single byte to the pipe to terminate the poll, and
the thread will exit.
Also, and this is related, is there a version of popen() (or some library
or something available) that is bidirectional - i.e., you can both write
and read from it - for example, you could run the Unix 'sort' utility this way - send it some data, then read back the sorted result (*).
On Thursday, January 7, 2021 at 11:20:00 AM UTC-8, Kenny McCormack wrote:
...
Also, and this is related, is there a version of popen() (or some library
or something available) that is bidirectional - i.e., you can both write
and read from it - for example, you could run the Unix 'sort' utility this >> way - send it some data, then read back the sorted result (*).
One classic (i.e., "decades old") and portable inside POSIX technique
that solves a large subset of this problem space is to use a process sandwich, where you create two pipes, then fork twice with one child
execing the target utility after some fd swizzling, with the other
child serving as the writer/source and the original process being the reader/sink**.
spudisnotyourbud@grumpysods.com writes:
On Tue, 12 Jan 2021 17:53:09 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote: >>>spudisnotyourbud@grumpysods.com writes:
On 11 Jan 2021 16:36:37 GMT
Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> wrote: >>>>>gazelle@shell.xmission.com (Kenny McCormack) writes:
Also, and this is related, is there a version of popen() (or some library >>>>>>or something available) that is bidirectional - i.e., you can both write >>>>>>and read from it - for example, you could run the Unix 'sort' utility this
way - send it some data, then read back the sorted result (*).
In Solaris there is a p2open()/p2close() as part of libgen; I'm not sure >>>>>whether it is common.
There is, of course, a risk: if you write to one end but you are not >>>>>reading the other end at the same time, you might be blocked by the >>>>>other program which is waiting for your to read but you are blocked >>>>>trying to write more. Using threads would fix that.
Or alternatively you could be sensible and use select/poll multiplexing on >>>> the descriptor returned from fileno() instead of messing around with >>>threading
and all the nonsense that goes with it.
Something like this is much simpler with threads which can block >>>individually.
It really isn't. But if you only know how to use a hammer...
It is
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 75:32:16 |
Calls: | 6,489 |
Calls today: | 2 |
Files: | 12,096 |
Messages: | 5,276,081 |