[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.
> Regards,
> Bjorn