|
|
Oh no! I already exceeded my booze quotum yesterday
|
|
|
|
|
RickZeeland wrote: I already exceeded my booze quotum
If a body could just fin' oot the exac' proper proportion o' quantity that ought to be drank every day... I verily trow that he micht leeve for ever... and that doctors and kirkyards would go out o' fashion.
I assume that you've already discovered that. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
My departed father believed in the therapeutic value of a daily glass of scotch. He lived to the ripe old age of 98!
Get me coffee and no one gets hurt!
|
|
|
|
|
My active and healthy 81-year-old father believes the same. The exact amount needs some fine-tuning, but they seem to be on the right track.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Hmm, makes me want to listen to Deacon Blues by Steely Dan.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
|
A ruined coffee and a wasted scotch...
|
|
|
|
|
Implementing a windows service in C# is bogus. The problem lies in ServiceBase.Run which blocks with no way to execute code "inside" its loop. This forces you to spawn a message pump on something other than the main thread which severely complicates if not eliminates the ability to use a SynchronizationContext - i might be able to do it, but not without wrapping the entire service architecture they provided, and presenting something different - which i really don't like.
Furthermore I had to dig through a now defunct former microsoft site on webarchive just to find this:
Sorry for the lack of communication yesterday. It's taken us a while to run down the proper resolution for this.
We've updated the documentation for SystemEvents.TimeChanged, but it takes a while for MSDN and other sources to refresh. The gist of the product team's response was that this event will not fire as long as the message pump is not running, and the documentation will now reflect that. Glenn is investigating a workaround to get the message pump running in a Windows service, and if it proves viable we'll add it to the doc and share it with you.
Django Wexler
.Net Client UE
*headdesk*
Real programmers use butterflies
|
|
|
|
|
And MS has reasonably good documentation. You should have seen the cr@p NetWare (in the 1990's) tried to pass of as adequate documentation for their NLM architecture.  
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
i don't see why they block. There's no reason for ServiceBase.Run() to block. It just causes a bunch of problems.
Real programmers use butterflies
|
|
|
|
|
|
Yeah I'm aware of those frameworks. I'm making kind of a C# wrapper for a service that's more geared toward parallel programming, and using messaging both inproc and out of proc to do thread synch (in proc) and remote communication with the controller app (out of proc)
Plus it's self hosting singleton app as well and can be run/stopped/installed/uninstalled with command line switches too.
It's a mess to develop, the messaging in particular is very challenging. I enjoy a challenge but I may have to work on this in fits and starts for a bit before I get any traction with it.
Real programmers use butterflies
|
|
|
|
|
And then you will have to rewrite everything for .NET Core 
|
|
|
|
|
Pardon a simple-minded question (or two), but... why does a service (which has no UI) need a message pump?
OK. So there are obscure cases where you must have a message pump, even in a service without a UI. Can't you just spawn a UI thread and pump the messages in that?
Software Zen: delete this;
|
|
|
|
|
For thread synchronization and for IPC. It's using message passing for that.
I could do Application.Run and then use WindowsFormsSynchronizationContext or whatever it is, but I'd rather not, as that's sloppy as hell.
Real programmers use butterflies
|
|
|
|
|
I assume you've looked at Topshelf[^], and the ActionThread class from Stephen Cleary's Nito.Asynchronous[^] library?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I haven't seen TopShelf but I have heard it mentioned before
The Nito.Asynchronous library I've looked at but while it's fascinating, i don't think it solves my problems with ServiceBase.Run()
What would be easy in an unmanaged service has become astoundingly difficult in .NET because of how they designed - in particular - ServiceBase.Run()
You know why I think they did it? It's easier for the beginners when your service doesn't exit at the end of your Main() function.
So my guess is Run() just blocks for that reason. It's ridiculous the idea that more advanced developers would have to suffer the limitations put in the framework for beginners. One of the reasons I liked .NET in first place is it doesn't "hide" anything. Everything is exposed if you know where to look. The training wheels are optional.
But ServiceBase.Run() seems to be a break from that pattern.
Edit: Oh no, I forgot about the Service Control Dispatcher thread that win32 needs to host services. Looks like Run() is being tied up there. That's at least reasonable, as I can shift that to any thread I want.
Real programmers use butterflies
modified 28-Jul-20 5:41am.
|
|
|
|
|
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end.
Usually, you have a fixed number of "messages" that the other side understands, but what if you could send *code* in the stream, even across process or network?
Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all.
There are two problems with this - complexity and security.
There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^]
Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service.
This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. 
Real programmers use butterflies
|
|
|
|
|
Who's the "user"? Most can't formulate a SQL query. You'll wind up with "libraries" (somewhere) in any event.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
The client software would deal with the complexity. Most of the dev end would be on the client code, since the service itself can be extended. I wouldn't expect a user to ever touch the bytecode
Real programmers use butterflies
|
|
|
|
|
Quote: There are two problems with this - complexity security and security.
FTFY
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
With the VM you can give it access only to certain things. My memory is a managed byte array with clear bounds, my set of instructions are limited to the low level operations the server is capable of, so say you did this with a machine with like 4 tesla cards (or whatever they're calling them today), and the clients could offload rendering operations (not necessarily realtime, but quick)
then your client wants to be able to say, motion blur something. You could write the transform for that in the bytecode.
What instructions the VM takes depends on what the service does. But I don't think custom graphics filters for example, would pose much security risk. If all your instructions deal in math or pixels and polygons.
Real programmers use butterflies
|
|
|
|
|
The problem there is the same as most "exploits" on Windows (and other systems, including Linux based stand alone hardware): any tiny mistake can expose stuff you didn't expect to. Just think of the number of buffer overrun exploits you heard about a few years ago. Allowing "downloaded code" to run is always a security risk, even if you are pretty sure nothing can get outside the sandbox ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
You're not wrong
This is why we can't have nice things.
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
