Date: Thu, 23 Dec 1999 11:30:29 +0800 From: miaobo@mail.zhongxing.com To: Mark Newton <newton@internode.com.au> Cc: hackers@freebsd.org Subject: ΄πΈ΄:Re: ASYCH/message-based programming style Message-ID: <48256850.00113AC7.00@mail.zhongxing.com>
next in thread | raw e-mail | index | archive | help
hehe, I forgot this is BSD list that all IPC topics can be done with the
control of various file descriptors that can be manipulated by select(). No
need of SYSV ipc method maybe. :-)
But for signal handling, it's somehow different, e.g. I have 10 processes
that need 10 indidual ASYCH timers, can I set 10 different signal handler
using signal() and call alarm(), then be correct each time when a timer
expires, a SIGALRM will be delieved to the correct process that further
traped it? Or, how can I deal with this kind of thing?
OTOH, signal may interrupts the sleep of syscalls in kernel and jump to
signal handler, we must check this situation with EINTR in our program, or
sometimes use sigsetjmp()/siglongjmp(), this makes the program's logic
unclear, I think.
I am sorry I don't care the graphic or I/O, I just want to know if I want
to implement event based programming on UNIX, what should I do? So comes my
question about the procedures from NIC receive a data packet to app's
blocked read() returns.I guess knowing may be helpful. Can you refer the
possible useful resources to me? Thanks.
regards!
On Thu, Dec 23, 1999 at 10:20:04AM +0800, miaobo@mail.zhongxing.com wrote:
> I think, compared to the application programming style of Win32, which
is
> asychronize and event/message based, application developing under UNIX
is
> so different.
Yup, that's why we like it :-)
> Here under UNIX, I guess the programmers need to take care of
> all sychronization IPC topics in the code, that is, if a process has 2
TCP
> socket connection, one pipe, and one SYSV msg id to listen on, the
control
> of program instruction flow will be hard if we don't want access to
> busy-wait situation, Although we can use select() to solve part of the
> problem,
Sorry? select() solves *all* of the problem: Notification of asynchronous
data delivery, timeouts, multiplexed IO; What problem can't you solve
easily and cleanly with a select()-driven state machine? (bearing in
mind that Win32 programs are essentially event-driven state machines).
> I think it's not yet enough. And handling asychronize events under
> UNIX, such as signal delievery and trapping is hard,
What's hard about signal(2)?
> the logic of the code
> will be unclear, and we only have one asych timer to
> use(alarm()/setitimer() share the same timer) and under MT programming
we
> even need to consider sychronization primitives' ASYN signal or
> cancellation safety. So I wonder if there can be any ASYN mechanism in
UNIX
> application programming in which All incoming I/O and IPC data are
> represented by events that contains the "pointer" to data itself, which
is
> Win32 style like. This maybe hard that it needs modification on kernel,
> such as implementation by Solaris2 of POSIX4 aio_read()/aio_write().
FWIW, FreeBSD implements aio_read() and aio_write() too, as does Linux,
IRIX and essentially every other UNIX variant. That does what you appear
to want, so I'm still wondering what you find deficient about the UNIX
approach.
> Or, just for historical reasons that UNIX just don't have this kind of
> mechanism?
It does, and has had for some time. Scatter-gather I/O via readv() and
writev(), and asynchronous I/O via aio_read() and aio_write() have been
with us for a very long time now.
> As I think, message-based programs is easier to write and the
> logic will be clearer.
Win32 forces you to think about messages, which are abstractions invented
by the API.
UNIX programs tend to be data-driven, which forces you to think about the
actual data you're trying to manipulate, instead of some artificial
construct designed by the writers of the OS.
I leave it to you to work out which approach makes more sense.
> Someone told me that message-based procedures are slower than SYCH
ones
> just like unix does, I don't why they say so if it is true, do you have
any
> comment about this? That is, can anyone introduce the procedures that,
from
> NIC receives a packet to applcation's unix blocked read()
returns/win32's
> application is informed by an event to me?
You're trying to shoe-horn events into an OS which doesn't follow an
event-driven paradigm; no wonder you're having trouble. Events are
bogus; The computer doesn't think in terms of events, so why should the
OS pretend it does? Think about your data, the operations you want to
perform on it, and the order in which you want to perform them; I/O
driven state machines are a good fit.
- mark
--
Mark Newton Email: newton@internode.com.au
(W)
Network Engineer Email: newton@atdot.dotat.org
(H)
Internode Systems Pty Ltd Desk: +61-8-82232999
"Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48256850.00113AC7.00>