From owner-freebsd-hackers Wed Dec 22 19:32:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.zhongxing.com (szptt103-147.szptt.net.cn [202.103.147.133]) by hub.freebsd.org (Postfix) with SMTP id CB6FE15784 for ; Wed, 22 Dec 1999 19:31:43 -0800 (PST) (envelope-from miaobo@mail.zhongxing.com) Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 48256850.001374A5 ; Thu, 23 Dec 1999 11:32:30 +0800 X-Lotus-FromDomain: ZTE_LTD From: miaobo@mail.zhongxing.com To: Mark Newton Cc: hackers@freebsd.org Message-ID: <48256850.00113AC7.00@mail.zhongxing.com> Date: Thu, 23 Dec 1999 11:30:29 +0800 Subject: ΄πΈ΄:Re: ASYCH/message-based programming style Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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