05270: All systems using sdlsocket: sdlsocket loses input buffer

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
05270	Core	Minor	Always	Aug 25, 2013, 17:15	Aug 26, 2013, 01:21

Tester	mizapf	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	Open	OS
Status [?]	Confirmed			Driver
Version	0.149u1	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	05270: All systems using sdlsocket: sdlsocket loses input buffer
Description	The socket is designed as a special sdlfile which allows for input and output operations. That is, you can perform read and write operations on that sdlfile. However, once you do a core_fwrite, the input buffer will be flushed (file->bufferbytes = 0), and all data in the input buffer that have not been read at that point of time are lost. This is not the expected behavior of a socket which is supposed to have independent input and output queues.
Steps To Reproduce
Additional Information	I noticed this problem when trying to find out why the RS232 connections are not reliable that I implemented some time ago in MESS/ti99_4x. I'm using a socket connection to an external tool that interfaces with the PC UART. I assumed that it was safe to do repeated fread operations with 1 byte, keeping the received data in the receive buffer of the UART. I did not expect that a write operation (for handshake or echo) wipes the buffer. One workaround is that I include a private buffer in my serial adapter emulation so that I quickly pull out all data from the sdlfile before a write occurs. We could also think about ways to fix the sdlsocket implementation because this will become a general issue whereever a socket is used for bidirectional communication. Added 08-14-2015: "..found a workaround, as described there (see ti_rs232.h:81) which is working well enough. The problem (cleaning the buffer) is still there."
Github Commit

Flags
Regression Version
Affected Sets / Systems	All systems using sdlsocket

Attached Files