[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Backround process, fork & vfork, synchronization methods?
> Normally in UNIX you don't really mesh together "drivers"
> like this into
> the user-programs, use callbacks and stuff. It's typical of
> Win32 but it's
> not typical in UNIX.
I guess it is my Win32 programming backround showing here. ;)
> Having said that, there are two easy ways to solve it without
> forking off
> the "driver":
> 1) put the driver in a completely separate program, and pipe
> it into the
> user-program somehow (like the user-program opens a pipe and
> select() on
> it to know when the serial driver has gotten the "magic" string)
I guess using select would force my user app to poll for the
"magic string", so my main app would look something like:
if (my_driver_magic_string_received(0 /* timeout */) == TRUE)
// do something here
> 2) use asynchronous I/O - the driver is a library linked with the
> user-program, and upon initialization it registers the SIGIO signal
> handler, and opens the serial port with asynchronous I/O enabled. when
> something arrives, the signal will be raised and your driver
> can strut its
> stuff asynchronously. this is not implemented in Linux 2.0
> AFAIK. another
> reason to go with 2.4 and Etrax100LX...
Thanks for the information, I may give this method 2 a try.
> > Question: Does Axis/Cris provide standard Unix synchronization
> > methods like semaphores or mutexes? What kind of interprocess
> > communication methods (pipes, message queues etc.) are supported?
> Our library for the 2.0 Linux does not implement user-level
> semaphores/mutexes (not that it is particularly difficult to do it
Does the previously mentioned Linux 2.4 support those? I assume
2.4 will be released in April?
> yourself..). I don't remember what SysV IPC mechanisms
> actually work. All
> the traditional stuff like pipes/fifos work of course.