Unix Programming - Re: Function: int recv (Socket, Buffer,Length, Flags) is returning with the error num

Author

Re: Function: int recv (Socket, Buffer,Length, Flags) is returning with the error num

monty

2007-07-25, 7:07 pm

On Jul 25, 1:50 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> sc...@slp53.sl.home (Scott Lurndal) writes:
>
>
>
>
>
>
> I was refering to the indirect 'worse is better'-quote. The reason
> (some) UNIX(*) system calls are interruptible is because there could
> be a reason to interrupt them. One would assume this to be even more
> true on early UNIX(*), before 'synchronous I/O multiplexing' was
> invented.
>
> A characteristic of earlier Unix systems is that if a process
> caught a signal while the process was blocked in a "slow"
> system call, the system call was interrupted. The system call
> returned an error and errno was set to EINTR. This was done
> under the assumption that since a signal occurred and the
> process caught it, there is a good chance that something has
> happened that should wake up the blocked system call.
> [APUE, 1st ed., p. 275]
>
> [...]
>
>
>
> To return to user space, the process has to return to user
> space.
>
>
> #include <signal.h>
> #include <stdio.h>
>
> static void handler(int unused)
> {
> puts("something stopped me");
> exit(0);
>
> }
>
> int main(void)
> {
> signal(SIGALRM, handler);
> alarm(3);
> while (1);
> return 0;
>
> }
>
> It follows that this program can never stop, because the SIGALRM
> cannot be delivered. It stops, though, at least on Linux 2.6.
>
>
> An example of the opposite (that I happen to have written ;-):
>
> static int wcomplete_wait(struct file *file)
> {
> wait_queue_t wait;
> volatile struct usblp *usblp;
> int have_signal, complete, rc;
>
> usblp = file->private_data;
>
> if (!usblp_wcomplete((void *)usblp)) {
> if (file->f_flags & O_NONBLOCK) return -EAGAIN;
>
> init_waitqueue_entry(&wait, current);
> add_wait_queue((wait_queue_head_t *)&usblp->wait, &wait);
>
> goto check_status;
> do {
> schedule();
>
> check_status:
> set_current_state(TASK_INTERRUPTIBLE);
> have_signal = signal_pending(current);
> complete = usblp_wcomplete((void *)usblp);
> } while (!(complete || have_signal));
>
> set_current_state(TASK_RUNNING);
> remove_wait_queue((wait_queue_head_t *)&usblp->wait, &wait);
>
> if (!complete) return -EINTR;
> }
>
> rc = usblp->writeurb->status;
> return rc;}
>
> [Linux 2.4 USB printer driver 'with some modifications', caller is
> write/ writev]
>
> For a blocking write, this is called after the URB (USB request
> buffer) has been submitted to the host controller for transmission.
> There isn't even a theoretical possibility of 'rolling this back' (see
> OHCI spec).
>
>
> Quoting APUE again (p. 277): "One of the reasons 4.2BSD introduced the
> automatic restart feature is because sometimes we don't know that the
> input or output device is slow".- Hide quoted text -
>
> - Show quoted text -

Hi Guys,

I am a new to the unix and thread programming and the discussion is
going above my understanding; apologies for this.
I have read suggestions from all. But I m unable to implement these
thing on my application.
I have tried recieving the message again $ again but it's going into
the infinte loop i.e. signal has occured at the start of the system
call I guess (like said by scott). He has suggested that "one must
roll-back the kernel state to that at the time of the system call";
Scott Can U please tell me how do i acheive this?

Guys i am in trouble right now and requesting all of you to provide me
a solution to the problem for now. Please tell me which are all the
functions I can use to supress the signal before calling the recv
function.

Thanks....looking forward to get help....

Sponsored Links