All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Samwel <bart@samwel.tk>
To: Libor Vanek <libor@conet.cz>
Cc: "Richard B. Johnson" <root@chaos.analogic.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Read from file fails
Date: Wed, 05 May 2004 13:50:03 +0200	[thread overview]
Message-ID: <4098D4EB.8070002@samwel.tk> (raw)
In-Reply-To: <20040505112218.GA7733@Loki>



Libor Vanek wrote:

>>>>>OK - how can I "notify" userspace process? Signals are "weak" - I need
>>>>>to send some data (filename etc.) to process. One solution is "on this
>>>>>signal call this syscall and result of this syscall will be data you
>>>>>need" - but I'd prefer to handle this in one "action".
>>>>
>>>>My first thoughts are to make it a blocking call.
>>>
>>>You mean like:
>>>- send signal to user-space process
>>>- wait until user-space process pick ups data (filename etc.), creates 
>>>copy of file (or whatever) and calls another system call that he's finished
>>>- let kernel to continue syscall I blocked
>>>?
>>
>>No, more like:
>>- user-space process calls syscall, which blocks.
>>- kernel captures a file write event, puts the info in some kind of 
>>queue, wakes up the user-space process and then waits for some kind of 
>>acknowledgement to be returned so that it may continue.
>>- user-space process wakes up, the syscall completes, and passes a 
>>filename etc. to user-space. Copies the file, and calls a syscall to 
>>signify "hey, I'm done with that file". This syscall wakes up the kernel 
>>stuff that was waiting for this acknowledgement.
>>- file write event continues
>>- repeat from start
> 
> OK - I'm thinking of using semaphores to "block" system call - is there something why this is not a good idea?

Semaphores are useful to protect a shared resource (and you might want 
to use those to protect your queue of filenames to copy), but not for 
transferring control between threads. I think you might want to look at 
wait_queue, wait_event, wake_up and things like that.

--Bart

  reply	other threads:[~2004-05-05 11:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-03  0:00 Read from file fails Libor Vanek
2004-05-03 13:11 ` Richard B. Johnson
2004-05-03 15:06   ` Libor Vanek
2004-05-04  0:47     ` Richard B. Johnson
2004-05-04  1:19       ` Libor Vanek
2004-05-04 13:49         ` Richard B. Johnson
2004-05-05 10:34           ` Libor Vanek
2004-05-04 14:31         ` Bart Samwel
2004-05-05  9:54           ` Libor Vanek
2004-05-05 10:04             ` Bart Samwel
2004-05-05 10:19               ` Libor Vanek
2004-05-05 10:45                 ` Bart Samwel
2004-05-05 11:22                   ` Libor Vanek
2004-05-05 11:50                     ` Bart Samwel [this message]
2004-05-05 10:54                 ` Denis Vlasenko
2004-05-05 11:58                   ` Michael Clark
2004-05-04 18:45         ` Paulo Marques
2004-05-05  9:47           ` Libor Vanek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4098D4EB.8070002@samwel.tk \
    --to=bart@samwel.tk \
    --cc=libor@conet.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.