sockets suck...

@LiveForIt
Quote:
I'm not too sure what you mean here. Is it ioctl(), and if so what parameters does it take??

I'm pretty sure, that I need smth with a signal because the whole event dispatcher thing is based on signals (like from intuition msg ports etc.).

int readbuf;

ioctl( client -> client, FIONREAD, (void *) &readbuf );

if (readbuf>0)
{
data = (void *) malloc( readbuf );
read( client -> client, data, readbuf );
}

I agree it good to use signals, but you can also do it whit busy loops.

@LiveForIt

Yeah, looks like I will have to. Kind of a bother though, it would have been perfect with signals. Right now I'm driving the input with a QTimer, which is just plain ugly. And also it is really bothering me, that I can't figure out _why_ it doesn't work. Oh well...

By the way: I want to change the title of the thread, but I can't see any edit button under the first post. Is this a bug or is it intentional??

what happens if you use WaitSelect instead of Wait ?

Last item in bsdsocket autodocs.

@broadblues

Hey, thanks! I will give it a shot.

@broadblues

Ok here is my first try at WaitSelect, and it doesn't work as expected:



It keeps saying "bad file number". What could I be doing wrong??

EDIT: Also I still cannot edit posts from past sessions. Is that a known issue or is it only me??

Becouse you are mixing Newlib/clib whit bsdsocket.library maybe.

Note: If I replace ISocket->WaitSelect() with select() it "works", so I'm inclined to think, that there is a bug in bsdsocket.library. Also, I _need_ the dual functionality of fd's and signals for qt, so just replacing with select() is not going to be any good for my purpose.

@LiveForIt

I have tried to remove the safewrite() line, but still the same. Which calls exactly do you think could the problem in this regard?

EDIT: Ahhh.... I understand now. I was calling socket() which is newlib instead of ISocket->socket() which is bsdsocket etc... Everything now works very fine, I just need to rewrite the socket handling code in Qt to take my new knowledge into accound. Thanks!

On the other hand, this is not going to help a lot, because what I was really fishing for was some sort of pipeline going from a QProcess to its ancestor. This is not going to work with bsd sockets because there is no way to redirect output from a process to a bsd socket, only to DOS filehandles and newlib fd's. This really sucks...

(And by the way, I tried just substituting IExec->Wait(mask) with ISocket->WaitSelect(0, NULL, NULL, NULL, NULL, &mask) and it blocks as well.)

Hmm, you could create a socket-handler which can open and send/recv data from sockets... actually, isn't this what the TCP: handler pretty much does? Although that connects to a host as well, which you probably don't want.

I don't think you can send data to a socket which isn't connected, can you?


PS sorry for my earlier unhelpful comment, I wrote more and then retracted it because it was nonsense.

@Alfkil
If I read you correctly you're trying to do ipc with sockets? That's a unix thing, I don't think that there's an amiga equivalent, or at least I've not heard of it.

What data are you trying to transfer?

Would a PIPE: suffice?

Quote:

I'd guess that's because if you set all those values to NULL then all you've got left is the "embeded" IExec->Wait()

@broadblues

I am now using a PIPE: to redirect input and output from a child process (for QProcess). Only one disadvantage: I cannot get a signal when data arrives, so I need to check manually if data has arrived. Other than that it works ok.

IRC: The problem is that you actually sometimes use the methods for your own opened ISocket interface, and sometimes for the automatically opened one.

I.e. change


to



And it should work. I got this myself a while ago, and if I remember correctly, the solution is as above.

Edit: saw that you got it sorted... and that I was rather late. I blame that I'm not used to dates being given like month/day making me think one recent post was from the 4th of may, and not the 5th april. :)

Quote:
Seems like it would be faster just to send an exec message containing a buffer pointer; which would signal the parent process when the message arrives. Of course, I don't really know what you are trying to do with data transfers but it seems like passing data through a PIPE is just an extra step.

@xenic

What I'm trying to do is to redirect stdout from a child process to a buffer to be read by the parent process. For this I need to use a PIPE.

Quote:
I see. In that case maybe you could redirect the child stdout to a temp file (T:myfile) and set up a file notification on the file in the parent process. If you're going to use a DOS device for data transfer I don't think it makes much difference whether the device is PIPE: or RAM: (where T: is usually located). I tried setting up a notification on a PIPE using the WaitNotify command from OS4Depot but it doesn't seem to work. That's a shame since it would be a perfect solution for you. Adding notification ability to PIPE: (queue-handler) would make a nice improvement for the next OS4 update.

@xenic

Ok thanks for the hint. I think though that I'll stick with my current solution for the time being unless someone suddenly _really_ needs that extra functionality.