[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:	DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:	Welcome to the Digital UNIX Conference
Moderator:	SMURF::DENHAM

Created:	Thu Mar 16 1995
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	10068
Total number of notes:	35879

8923.0. "Cancel read from a socket?" by CSC32::C_REESE (Fine. How are you?) Fri Feb 21 1997 11:21

Hi Gang!

I have a customer who wants to know how to cancel a read on a DLI socket. 
He has not found a good way to do this.  In Dunix 4.0 he has found that
he can kill the thread that posted the read.  This effectively cancels the
read but he has to restart the socket.  He feels that sometimes he looses
data with this approach.  He has not proven this however. 

He has found that calling the shutdown(2) system call will have the 
desired effect of cancelling the read but it has the undesireable side
effect of closing the socket.  He doesn't want (or need) to close the 
socket. 

In 3.2C he has not found any way of cancelling the read on the DLI socket. 

On other vendors versions of UNIX he has found that they provide an 
SIOCIFRESET ioctl that may be used to cancel I/O operations on the device.
It appears that Dunix does provide this ioctl for many network devices 
(fta, fxx, fza, tra, etc.) but NOT the tulip (tu) device.  It sounds like
this would solve his problem. 

So my questions are: 

1) Is there a way of cancelling an I/O on a DLI socket that has not been
covered?

2) Should the tulip driver support the SIOCIFRESET ioctl?  

As always, any and all help is greatly appreciated. 

Carl Reese
CSC/Colorado Springs

T.R	Title	User	Personal Name	Date	Lines
8923.1		VAXCPU::michaud	Jeff Michaud - ObjectBroker	`Fri Feb 21 1997 11:34`	9
	Instead of blocking in a read(2) or recv(2), they can instead use select(2). They can they timeout the read if that's what they are really trying to do, or in addition to selecting on the DLI socket, also select on one end of a pipe(2), and then when you want to have another thread to wakeup the thread blocked in select(2), simply write(2) a single byte of data on the other end of the pipe. Why do they want to cancel the read anyways?
8923.2	Need unix equiv of SYS$CANCEL	CSC32::C_REESE	Fine. How are you?	`Fri Feb 21 1997 16:32`	5
	They are porting an application from VMS to Digital UNIX. They need the UNIX equivalent of a VMS SYS$CANCEL(). Carl
8923.3		VAXCPU::michaud	Jeff Michaud - ObjectBroker	`Fri Feb 21 1997 17:17`	10
	> They are porting an application from VMS to Digital UNIX. They need > the UNIX equivalent of a VMS SYS$CANCEL(). UNIX isn't VMS of course, and that doesn't answer the question. "Why" does their application need to do this? In any case, my previous suggestion about using select(2) and a pipe(2) pair of file descriptors will do what they want. But if we knew what they really needed, there may be better solutions.
8923.4		COL01::LINNARTZ		`Mon Feb 24 1997 04:52`	7
	I would also follow the select/poll way. you could also use the solution of setting up a timer before the read, and than checking the the returncode and if errno is set to EINTR perform your action in case of timeout. Pit
8923.5	Mixing signals & threads is something I try to avoid	VAXCPU::michaud	Jeff Michaud - ObjectBroker	`Mon Feb 24 1997 10:46`	9
	> you could also use the solution of setting up a timer > before the read, and than checking the the returncode and if > errno is set to EINTR perform your action in case of timeout. The reason I didn't suggest using signal's as an alternative is that threads are involved, and the mixing of threads and signals can get tricky depending on which thread gets delivery of the signal.
8923.6	oops, right Jeff shame on me	COL01::LINNARTZ		`Mon Feb 24 1997 10:49`	1